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FOREWORD 


The Spacelab User Implementation Assessment Study was conducted to assess 
and minimize the capital investment of the National Aeronautics and Space 
Administration for the integration and checkout of Spacelab payloads such as 
Langley's Advanced Technology Laboratory. The study was conducted by the 
Space Division of Rockwell International Corporation under Contract NAS1-12933 
for the Langley Research Center. Mr. F. 0. Allamby was the technical studv 
manager for the Langley Research Center. In addition, this study received 
agency-wide guidance and evaluation from the Steering Group for Payloads 
Operations Concept Studies, directed by Mr. W. 0. Armstrong, to maximize the 
objectivity and applicability of the study data. 

The final report consists of an executive summary and four technical 
volumes as illustrated in the accompanying figure. A succinct summary of the 
study is presented in the executive summary. Three of the four technical vol- 
umes present the analyses and trades performed during the course of the studv. 
The fourth volume contains five appendixes, which delineate detailed data per- 
taining to the installation and checkout of Spacelab payloads such as the ATL, 
and a computer cost model utilized in the compilation of programmatic resource 
requirements. The contents of the volumes are described below. 

EXECUTIVE SUMMARY 

* Study overview — objectives, study approach. 

* Synopsis of development of candidate processing concepts — 
complete Spacelab and pallet-only configurations. 

* Summary of integration and checkout optimizations — 
checkout approach, ground operations processing cycle, 
personnel, ground support equipment and facility 
requirements . 

* Programmatic costing — mission-unique, sustaining, and 
non-recurring cost estimates for required personnel, 
material, travel, documentation, ground support equip- 
ment, and facilities. 

* Concept evaluations — flight-rate sensitivities and 
concept applicabilities. 

VOLUME I. CONCEPT DEVELOPMENT AND EVALUATION 

* Complete Spacelab processing concept development. 

* Pallet-only processing concept development. 
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EXECUTIVE 

SUMMARY 


• Study Objectives 

• Significant Results 

• Recommendations 


CONCEPT 

DEVELOPMENT 

& 

EVALUATION 


VOLUME I 


* 


• Candidate Processing Concepts 

• Integration & Checkout Task Descriptions 

• Processing Optimizations 

• Concept Evaluations 


CONCEPT 

OPTIMIZATION 


• Support Function Requirements 

• Responsibility Assignments 

• Test Philosophy 

• Checkout Approach 


Checkout Requirements 

'integrated Test and 
Operations Flows 


VOLUME 1 1 



<? 


RESOURCE 

REQUIREMENTS 

DEVELOPMENT 


• Mission-Unique Requirements 
•Sustaining Requirements 
•Non-Recurring Requirements 

• Programmatic Costs 


VOLUME III 


0 




APPENDIXES 

A. 

B. 

C. 

D. 

E. 

EXPERIMENT 

INSTALLATION 

TIME 

ESTIMATES 

EXPERIMENT 
CHECKOUT 
FLOW TIME 
ESTIMATES 

EXPERIMENT 

SUMMARY 

ACTIVITY 
DATA SHEETS 

SYSTEM COST 
MODEL 


VOLUME IV 


Study Reports 
iv 
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* Results of study optimizations In the areas of checkout 
requirements, simulator utilization, and configurational 
changes. 

* Flight-rate sensitivities — flight hardware, GSE, facility, 
and personnel. 

* Concept evaluations — integration center/launch site 
co-location, support module cognizance, WTR implications, 
general applicability, recommended ATL approach. 

VOLUME II. CONCEPT OPTIMIZATIONS 

* Supporting functions — development, definitions, and 
responsibility assignments. Identifies potential 
software applications. 

* Test requirements — checkout approach and requirements, 
test philosophy, and environmental test requirements. 

* Test and operations sequence — development of functional 
flows, detailed operations, activity data sheets, and 
integrated flows for both the complete Spacelab and 
pallet-only processing concepts. 

VOLUME III. RESOURCE REQUIREMENTS DEVELOPMENT 

* Requirements for mission-unique, sustaining, and non- 
recurring resources — includes personnel, travel, trans- 
portation, material, documentation, GSE, and facilities. 

* Programmatic costing — presents cost estimates for all 
resource requirements. 

* Cost-risk analysis — parametric evaluation of deletion 
of vibra-acoustic , thermal-vacuum and repeat functional 
tests. 

VOLUME IV. APPENDIXES A, B, C, D, AND E 

* Appendix A. Experiment Installation Time Estimates - Time 
estimates of the required experiment installation activities 
including (1) physical installation of experiment hardware 
in a rack, igloo, or on a pallet; (2) performance of elec- 
trical bonding checks; (3) complete mechanical interconnec- 
tion including fluid and electrical lines; and (4) performance 
of end-to-end continuity checks between the experiment con- 
nector and the interface connector at the experiment module/ 
pallet, support module/experiment module or igloo interfaces. 

* Appendix B. Experiment Checkout Flew Time Estimates - The 

general experiment checkout flow plus the time estimates for 


v 


SD 74-SA-0156 



Space Division 

Rockwell International 


each individual experiment in the ATL experiment complement. 

These time estimates detail the time required for: 

- Equipment setup and activation, including 
controls and display equipment. 

- Verification of the operation of mechanical 
devices of both pallet and rack-mounted 
sensors and auxiliary equipment. 

- Verification of data processing/ recording 
equipment and Instrumentation concurrent 
with checkout of the experiments. 

• Appendix C. Experiment Siomary - A summary of the require- 
ments and equipment utilized for each experiment Included in 
the study. The experiments are listed by discipline. 

- Navigation 

- Earth Observations 

- Physics and Chemistry 

- Microbiology 

- Environmental Effects 

- Components and Systems Testing 

The summary for each experiment includes the objectives or 
purpose, the description of the equipment utilized, the 
operation of the equipment, and the physical parameters of 
mass properties and equipment installation location (pallet, 
rack, igloo). 

• Appendix D. Activity Data Sheets - Detailed definitions of 
the test operations associated with each activity defined in 
the expanded functional blocks (detailed functional flows). 

The activity data sheets describe the operations involved 

and the resources utilized to accomplish the processing cycle. 

They cover the entire cycle from initial experiment installa- 
tion through the various integration levels (Experiment, III; 

Spacelab, II; Orbiter Cargo, I), and the refurbishment of the 
pallets, racks and/or igloos, following the completion of the 
mission. 

• Appendix E. System Cost Model - Description of computer cost 
model utilized in the study to compile the derived resource 
requirements into mission-unique, sustaining, and non-recurring 
cost categories. 

Within each volume, the term "concept" is used repeatedly and data are 
presented with respect to Concepts I through VIII. The concepts referred to 
pertain to alternate integration and checkout approaches for both the complete 
Spacelab (support module, experiment module, and pallet) and the pallet-only 
Spacelab configuration. The following two tables define, in general terms, 
each of the eight processing concepts that were definltized in this study. 
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Complete Space lab Processing Concepts 




OWNER 


_ INTEGRATION SITE 

CONCEPT 


RACKS 6 
RACK SETS 

PALLET 

EXPERIMENT 

EQUIPMENT 

SPACE LAB 

1 

1C 

1C 

1C 

1C 

1C 

1 1 

LS 

I c 

1C 

1C 

LS 

1 1 1 

LS 

1 c 

1 C 

USER 

LS 

IV 

LS 

USER 

USER 

USER 

LS 

V 

USER 

USER 

USER 

USER 

USER 


^SUPPORT MODULE, SUPPORT SYSTEMS, & EXPERIMENT MODULE STRUCTURE 


Pallet-Only Processing Concepts 


CONCEPT 

J OWNER 

| INTEGRATION SITE | 

PALLET 

IGLOO* 

EXPERIMENT 

EQUIPMENT 

SPACELAB 

VI 

1C 

LS 

USER 

LS 

VI 1 

1C 

LS 

1C 

LS 

VMI 

USER 

LS 

USER 

LS 


*SUPP0RT SYSTEMS IGLOO AND EQUIPMENT 
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AAFE 

ADDAS 

AEDC 

AIM 

AM 

ARINC 

ARS 

ASO 

ATCS 

ATL 

ATM 


CCTV 

CDMS 

CER 

C.G. 

CRTS 

CM 

CPSE 

CRT 

CSM 

CV-990 


DOMSAT 

DPC 

DUGS 


ECLSS 

ECS 

EDS 

EGSE 

E/I 

EM 

EMC 

EMI/RFI 

EPDS 

ERNO 

ESRO 
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ABBREVIATIONS AND 
ACRONYM LIST 


Advanced Application Flight Experiments 
Automated Digital Data Acquisition System 
Atomic Energy Development Center 
Apogee Insertion Motor 
Airlock Module (Skylab) 

Aeronautical Radio, Inc. 

Atmospheric Revitalization System 
Airborne Science Office 
Active Thermal Control Subsystem 
Advanced Technology Laboratory 
Apollo Telescope Mount (Skylab) 


Closed Circuit Television 
Command and Data Management System 
Cost Estimating Relationship 
Center of Gravity 
Circuits 

Command Module (Apollo) 

-Common-Payload-Support-Equipment . 

Cathode Ray Tube 

Command and Service Module (Apollo) 

Convair airplane used as test bed in airborne research by 
NASA-Ames Research Laboratory 

Domestic Satellite (commercial geosynch communications relay) 

Data Processing Center 

Drawings 


Environmental Control and Life Support System 
Environmental Control System 
Experiment Discipline Specialist 
Electronic Ground Support Equipment 
End Item (hardware) 

Experiment Module 
Electromagnetic Compatibility 

Electromagnetic Interference/Radio Frequency Interference 
Electrical Power and Distribution System 
European consortium developing Spacelab 
European Space Research Organization 
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FMEA Failure Mode Effects Analysis 

FO Flight Operations 


GSE Ground Support Equipment 

GSFC Goddard Space Flight Center 


IC 

ICD 

I/F 

IMS 

INSP 

IPS 

IU 


Integration Center (sometimes inferred to be MSFC) 

Interface Control Drawing 

Interface 

Information Management System 
Inspection 

Instrument Pointing System 
Instrument Unit (Saturn V Program) 


JCL Job Control Language 

JSC Lyndon B. Johnson Space Center 


KSC 


John F. Kennedy Space Center 


LL Lower Limit 

LS Launch Site 


MCC 

MCP 

MDA 

MGT 

MIL-SPEC 

MSFC 

MSOB (O&C) 

MSS 

MP 


Mission Control Center (at JSC) 

Monitor and Control Panel 
Multiple Docking Adapter (Skylab) 

Management 

Military Standard Specification 
Marshall Space Flight Center 

Manned Spacecraft Operations Bldg (now Operations & Checkout) 
Modular Space Station 
Mission Planning 


NASCOM NASA Communications Network 

NCR Non-Conformance Report 


OB CO 

OCC 

O&C 

OCP 

01 T 

OMS 

OWS 

OPF 


On-Board Checkout 

Operations Control Center (at Spacelab user's site) 
Operations & Checkout Building (formerly MSOB) 
Operational Checkout Procedure 
Orbiter Integrated Test 
Orbital Maneuvering System (Shuttle) 

Orbital Workshop (converted S-IVB structure — Skylab) 
Orbiter Processing Facility 


P 

PI 

PS 

PSS 


Pallet or Pallet Section 
Principal Investigator 
Payload Shroud (Skylab) 
Payload Specialist Station 


QC 


Quality Control 


R 

RAU 

R/I 

R&QA 


Rack or Rack Sets 
Remote Acquisition Unit 
Receiving/Inspection 
Reliability and Quality Assurance 
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SC 105 

SCM 

SE 

SIM 

SL 

SM 

SPECS 

SSP 

STDN 

STS 

SUIAS 

TCR 

TDRS 

T&0 

U 

UL 

WBS 

WTR 
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Spacecraft 105 (Apollo) 

System Cost Model 

Systems Engineering 

Scientific Instrument Model 

Space lab 

Support Module 

Specifications 

Space Shuttle Program 

Space Tracking and Data Network 

Space Transportation System 

Spacelab User Implementation Assessment Study 

Test and Checkout Requirements 
Tracking and Data Relay Satellite 
Test and Operations 

User (inferred to be Langley) 

Upper Limit 

Work Breakdown Structure 
Western Test Range 
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1.0 INTRODUCTION 


Volume II, Concept Optimizations, defines the integration and checkout 
activities associated with the ground operations for each Spacelab flight 
and establishes the preferred/optimal approaches to accomplish these activi- 
ties. Integration and checkout activities are divided into two parts, as 
illustrated in Figure 1.0-1. The tasks associated with each part of the 
integration and checkout activities are indicated in the figure. 



* Operations Analysis 

* Requirements Definition 

* System Design 

* Interface Hardware 

Fabrication 


* Experiment Installation 

* Spacelab Test and Checkout 

* Handling/Transportation 

Activities 


Figure 1.0-1. Spacelab Integration and Checkout Elements 

The support functions are defined for three types of activities: 

(1) mission-unique, (2) sustaining, and (3) non-recurring. The definition 
of the support functions is accomplished by the establishment of a WBS for 
each of the three types of activities. Each WBS contains only these tasks 
that relate to that particular type of activity. However, the WBS's are 
structured to facilitate the development of a composite WBS for all Spacelab 
integration and checkout activities. 
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The approach for the optimization of each type of support functions is 
also presented. The mission-unique support function optimization includes 
an evaluation of the roles and responsibilities of the Pi's and the payload 
integrators. The sustaining support functions are definitized by deriving 
a management organization at each center that is tailored/optimized to the 
requirements of each processing concept. Use of the nucleus of a systems 
engineering organization is indicated for the accomplishment of non-recurring 
support functions. Where applicable, the use of software to expedite the 
accomplishment of all support functions is indicated. In addition, flight 
software requirements are defined and a test and validation technique is 
established. 

Center support functions, which are concept-dependent, are defined by 
the use of derived responsibility criteria. These criteria are applied to 
key support function and hardware interfaces to identify primary, secondary, 
and supporting roles of the centers involved. 

The definition of test and operations activities includes a preferred 
checkout approach. The approach reflects the objective of minimizing both 
recurring and non-recurring costs of the NASA for integration and checkout of 
Spacelab payloads. Checkout guidelines are established that reflect a test 
philosophy that stresses the verification of planned flight operations. Veri- 
fication of functional operations rather than performance capabilities of the 
equipment is the objective of tests and operations activities. 

The feasibility of utilizing the Spacelab data management system (DMS) 
in the preferred checkout approach is evaluated. Both operating and memory 
capacities of the DMS are analyzed. 

The use of an SM simulator during Level III integration is compared with 
the use of the flight hardware to support checkout operations. This trade 
assesses the impact of including an SM simulator in the checkout sequence on 
total serial processing times of the flight hardware, and the required comple- 
ment of flight hardware to support the anticipated Spacelab traffic model. 

Checkout requirements are evaluated in three areas: functional, environ- 

mental, and operational. The functional requirements are analyzed for both 
the Spacelab/Orbiter and the experiment systems. The analysis of environmental 
checkout requirements involves the evaluation of six significant past space 
programs, the determination of trends in these past programs, and the applica- 
bility of the trends to an operational Spacelab program. Proposed Spacelab 
payload environmental verification techniques are defined. The operational 
checkout requirements include an analysis of the impact of payload cleanliness 
constraints and proposed shipping/transportation techniques on the sequence 
of Installations and test/retest activities. 

In the final part of the test and operations analysis, the test flow_ 
development is presented. The establishment of scenarios describing all of 
the test and operations activities relating to both the complete Spacelab and 
the pallet-only configurations are described. Expansion from functional block 
diagrams to at least two lower levels of detail is discussed. Integrated 
flight hardware processing timelines that reflect a summation of the expanded 
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test and operations details are presented. The serial flight hardware process- 
ing times for all eight concepts are summarized and compared. 

The final section of this volume summarizes the involvement of the payload 
integrator in experiment systems development activities. 
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2.0 SUMMARY 


The integration and checkout activities consist of two major sets of 
tasks: (1) support functions, and (2) test and operations. The support 

functions are definitized and the optimized approach for the accomplishment 
of these functions are delineated in Section 3.0 of this volume. Comparable 
data are presented for test and operations activities m Section 4.0 of this 
volume. 

The support functions were divided into three types of activities: 

1. MISSION UNIQUE - Must be accomplished for each flight. 

- Repeatable and can be considered directly 
attributable to the ground operations 
associated with an individual payload. 

2. SUSTAINING - Encompasses the administrative, management, 

and institutional base support functions. 

- Independent of flight rates and/or 
individual Space lab payload. 

3. NON-RECURRING - Activities that adapt an operational 

— — - — Spacelab/Orbi-ter-to the-speci-f ic-require= 

ments of a user. 

The Spacelab payload integration and checkout WBS that was presented in 
Volume I was subdivided to illustrate which elements or tasks are mission- 
unique, sustaining, or non-recurring support functions. The tasks that were 
applicable to each type of support function are shown in Figures 2.0-1, 

2.0-2, and 2.0-3. 

The optimization of the support function tasks is defined m detail in 
Section 3.2. This optimization was accomplished by establishing a preferred 
approach for each of the three types of activities. The approach for the 
accomplishment of mission-unique tasks was developed by first identifying the 
roles and responsibilities of the Pi’s and the payload integrator, and then 
synthesizing techniques to fulfill those responsibilities. Sustaining support 
functions were optimized by deriving a management/administrative organization 
that was tailored for each center’s role in each processing concept. It was 
recommended that non-recurring support functions be accomplished by the 
nucleus of the mission-unique systems engineering organization. 

The role of the PI in mission-unique support functions not only included 
the design, development, and performance verification of individual experi- 
ments but also the preparation of a data package for each experiment. This 
data package will include measurement and command lists, display nomenclature, 
support system requirements, trajectory constraints, operational procedures, 
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Figure 2.0-1. Mission-Unique Support Function WBS 
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Figure 2.0-3. Non-Recurring Support Function WBS 


ground truth site requirements, data processing/storage requirements, and a 
hazard analysis of the equipment and procedures. Identification of payload 
specialist skill requirements and the training of the payload specialists in 
t-he-operation of- the experiments-were_also - the_responsibility of-the Plls. 

Based upon the baseline data package prepared by the Pi's, the respons- 
ibility of the payload integrators was to integrate/combine individual exper- 
iment system requirements into a compatible payload. This integration 
encompasses mission analysis and planning, mission operations, and systems 
engineering tasks. Mission analysis and planning activities include develop- 
ment of mission and payload specialist timelines. Computer-aided techniques 
such as Langley's Manned Activity Scheduling System (MASS) were recommended 
to expedite the process and reduce costs. Mission operations included real- 
time mission support at the user's site, Spacelab and Orbiter operator centers, 
and ground truth sites. A facility at the user's site for real-time data 
evaluation was recommended. Computer-aided analyses and design was also 
recommended for the accomplishment of systems engineering tasks. Standardized 
Spacelab/Orbiter accommodations will permit computerization of wire routing, 
panel layouts, space allocations, power and thermal profiles, etc. 

In order to determine the roles of the individual centers in the accomp- 
lishment of the payload integration tasks, responsibility criteria were 
established (Table 2.0-1). The two principal themes of the criteria were 

(1) maintenance of owner cognizance throughout the integration process, and 

(2) configuration control of equipments and, most importantly, interfaces 
between assembly levels. The results of the application of these criteria 
to key integration and checkout interfaces are presented in Tables 2.0-2 and 
2.0-3 for each of the processing concepts. Primary, secondary, and support- 
ing roles of the involved centers are indicated. 
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Table 2.0-1. Responsibility Criteria 


DRIVER 



OWNERSHIP 

CONFIGURATION MANAGEMENT 

MINIMUM PI/USER INVOLVEMENT 

INTERFACE CONFIGURATION CONTROL BY 
OWNER OF NEXT LEVEL OF ASSEMBLY 

INSTALLATION SITE PROVIDES 
WORKING CREW; USER PROVIDES 
PAYLOAD SPECIALISTS 

STRUCTURE FOR CONTINUING ATL 
PAYLOADS 

FLIGHT OPERATIONS SOFTWARE 
PREPARED BY EXPERIMENT 
INTEGRATOR 

MODULE OWNER PROVIDES HARDWARE 
MODIFICATIONS 

GROUND TRUTH SITES OPERATED 
BY EXPMT INTEGRATOR AND PI 

CPSE CONTROL AND INVENTORY BY OWNER 
OF NEXT LEVEL OF ASSEMBLY 


Table 2.0-2. Key Experiment Integration Support Function Interfaces 
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Table 2.0-3. Key Experiment Integration Hardware Interfaces 
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In addition to the systems engineering tasks associated with the integra- 
tion of procedures and flight hardware, flight and ground operations software 
was also required. Eight potential mission-unique software packages were 
identified. The packages were: 


1.0 

Flight Operations 

5.0 

Orbiter Support 

2.0 

Checkout/Performance Monitoring 

6.0 

Repair /Refurbishment 

3.0 

Fault Isolation/Diagnostic 

7.0 

Data Reduction 

4.0 

Test and Validation 

8.0 

Data Analysis 


Fault Isolation/Diagnostic (Item 3.0) and Repair/Refurbishment (Item 6.0) 
were not recommended for experiment systems because of the flight-to-flight 
changes in experiment equipments. These two software items were recommended 
for Spacelab support systems. All other software packages were considered to 
be essential for the efficient accomplishment of support function tasks. 

Based upon extensive software studies conducted by JSC, KSC and MSFC, guide- 
lines were formulated for the preparation of mission-unique software. The 
principal theme of the guidelines was to utilize machines and computer lang- 
uage that are readily understandable and usable by a broad spectrum of 
technical personnel. Computer expertise should not be a pre-requisite for 
Spacelab /payload software development. 

The recommended approach for the test and validation of mission-unique 
Spacelab software is shown in Figure 2.0-4. In this approach, the PI can 
either provide a software module or a data package to the payload integrator. 
If the PI prepares only a data package, the payload integrator assembles a 
first-cut tape wherein the operations of the experiment and associated support 
systems are merged into one operating routine. 
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This routine (applications , and data modules) is loaded into a simulator 
of the Spacelab Control and Data Management System (CDMS) along with the 
executive and operating system software, concurrent with the installation of 
that set of experiment equipment. If the PI elects to develop his own soft- 
ware, he delivers the software module with the experiment hardware as an 
additional end item of flight hardware. 

In this approach, the debugging of the operating routine is accomplished 
during experiment installation and test; editing and modification (only the 
data module) is done on site by means of a real-time editor which is part of 
the test complex, but not part- of the CDMS. Validated data modules for 
individual experiments are then assembled (off-line) into a mission tape. A 
similar process would prepare the Spacelab housekeeping tape, at the next level 
of assembly. 

This approach for the test and validation of Spacelab payload software 
minimizes the transfer of software requirements and responsibilities, and 
also reduces the required number of validations. All six applicable Spacelab 
payload software packages can be tested and validated with this approach. 

The optimized test and operations checkout approach was established by 
utilizing the checkout guidelines illustrated in Figure 2.0-5. 


OBJECTIVE 

■ 

OPTIMIZATION FACTORS 

VERIFY EXPERIMENT 

I 

STRUCTURE FOR 

• SETUP 

I 

• PI/CREW ORIENTATION 

• CALIBRATION 

I 

• MINIMUM RETEST 

• ON-LINE FLEXIBILITY 

• OPERATION A 

1 

A « MISSION-TO-MISSION FLEXIBILITY 


££r2 


PRIMARY CHECKOUT PROVISIONS 


• C/0 OPERATIONS SIMILAR TO FLIGHT OPERATIONS 
•INTEGRAL CHECKOUT/MISSION PROG. DEVELOPMENT 
•INTEGRATED SOFTWARE/HARDWARE VERIFICATION 

• MAXIMUM USE OF FLIGHT SOFTWARE 

• ADAPTIVE PROGRAMMING APPROACH 


Figure 2.0-5. Checkout Guidelines 

These guidelines reflect a test philosophy that stresses the verification 
of planned flight operations by limiting testing to the verification of on- 
orbit operations. Functional verifications, not performance or capability 
evaluations, were to be conducted during flight hardware processing. 
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As illustrated in Figure 2.0-6, three approaches to achieve the checkout 
guidelines were evaluated. 
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Figure 2.0 6. Alternate Checkout Implications 


Analysis indicated that the computer-aided approach can be structured 
to meet all of -the checkout guidelines. A feasibility analysis of the capa- 
bility of the Spacelab Data Management System (DMS) to support Level III 
integration was conducted. Estimates of the ground and on-orbit data process- 
ing requirements for both Spacelab support systems and experiment systems 
were developed. The compatibility evaluation indicated that the DMS can 
accommodate both systems, provided additional mass memory (tape recorders) 
are provided. 

Use of an SM simulator during Level III integration was compared to the 
use of the flight SM. Total serial processing time of the flight hardware 
and the complement of flight hardware required to support the anticipated 
Spacelab traffic model were evaluated. In general, simulator utilization 
did not affect the serial processing time of the payload but did significantly 
decrease the required complement of flight SM's at higher flight rates. Use 
of a support systems simulator during Level III integration was adopted for 
all processing concepts. 


Three categories of checkout requirements were evaluated: functional, 

environmental, and operational. Within the area of functional checkout 
requirements, two major test activities were considered: Spacelab /Orbiter, 

and experiments. In this study, the Spacelab /Orbiter were considered on- 
going operational programs. Test activities involving these two program 
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elements were limited to functional reverification as required and interface 
verification. Complete functional verification of experiment systems and 
interfaces was required. Use of planned on-orbit operations during testing 
was to be maximized. 

The various environments that experiment equipment will be exposed to 
during payload processing and orbital missions were analyzed, and a preferred 
environmental verification approach was defined. Based upon the operational 
nature of the Spacelab/Orbiter, analytical techniques for environmental com- 
patibility evaluations of the integrated payload were selected. Only 
electromagnetic compatibility verification required empirical testing at the 
integrated payload level of assembly. Environmental testing of individual 
experiment equipments will be required. 

The recommended mode for the transport/shipping of assembled Spacelab 
elements was to utilize the 747 piggyback mode. If only racks and pallets 
were involved, and the combined pallet-sensor height was less than 11.5 feet, 
then the C-5A aircraft was the preferred shipping approach. Retesting after 
major moves was limited to receiving-inspection type activities. 

Test and operations sequences were derived from hardware processing 
scenarios for each concept. Major functional activities were defined and 
expanded at least two additional levels of detail. Time allocations were 
established for each expanded activity, and then summarized to an integrated/ 
contiguous sequence of tests and operations. Table 2.0-4 summarizes the 
serial processing times for the complete Spacelab concepts. A summation of 
the serial processing times for the pallet-only concepts is presented in 
Table 2.0-5. The differences in processing times between concepts for com- 
parable Spacelab configurations were due to shipping/handling variations. 
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Table 2.0—4. Summary of T&O Times for the Complete Spacelab Processing Concepts 



MAJOR FUNCTIONAL ACTIVITY 



OVERLAP PARALLEL - ERI . Al PR ° CC ?- S i. N . C ! tMtS 
TIME TIMES I I II I III I IV 


EXPERIMENT SHIPMENT 

EXPERIMENT INSTALLATION 

CONNECT SM INTERFACE SIMULATOR 

EXPERIMENT INTEGRATION 

GSE DISCONNECT 

RACKS /PALLET SHIPMENT 

MATE RACKS / PALLET -EM/SM SHELLS 

SPACELAB INTEGRATION 

SPACELAB SHIPMENT TO LAUNCH SITE 

SPACELAB 0FF10AD 

ORBITER CARGO INTEGRATION 

LAUNCH OPERATIONS 

MISSION OPERATIONS (REFI 

PCS Tf LIGHT OPERATIONS 

SPACELAB MOVE TO MS08 

SPACELAB SHIPMENT FROM LAUNCH SITE 

DEMATE EM/SM SHELLS 

RACKS /PALLET SHIPMENT 

REFURBISH RACKS /PALLET 

EXPERIMENT SHIPMENT 

REFURBISH SUPPORT SYS & EM/SM SHaLS 

P0ST-REFUR8ISH RACKS/PALLET SHIPMENT 


CONCEPTS I AND V ONLY 




1 9 

1.9 


2.6 

5 4 


1 2 

1 2 


6.7 

8 2 

8.2 




1 2 1.2 1.2 1 2 

6.7 6.7 6 7 

8.2 8.2 8.2 8.2 


TOTAL 

(WORKING DAYS) 



111.3 ( 115.8 122.3 115.8 11 L 



Table 2.0-5. Summary of T&O Times for Pallet-Only Processing Concepts 


MAJOR FUNCTIONAL ACTIVITY 


EXPERIMENT SHIPMENT 
EXPMT INSTALL. (PALLET/ IGLOO) 
CONNECT & CIO IGL/ORBITER SIM SET 
EXPERIMENT C/0 & INTEGRATION 
GSE DISCONNECT 
PALLET/ IGLOO SHIPMENT 
P/IGL& PSS EQUIP ARRIVAL & R/l 
MATE PALLET & IGLOO (SUPPORT SYST) 
SPACELAB INTEGRATION 
ORBITER CARGO INTEGRATION 
LAUNCH OPERATIONS 
MISSION OPERATIONS (REF) 

POSTFLIGHT OPERATIONS 
REFURBISH SUPPORT SYSTEMS IGLOO 
PALLET/ IGLOO SHIPMENT 
REMOVE EXPMTS/EQUIP FROM P/IGLOO 
EXPERIMENT SHIPMENT 
REFURB/RECONFIG PALLET & IGLOOS 
P0S1-REF 





TOTALS 


111.7 106.1 106.11 
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3.0 SUPPORT FUNCTIONS 


Integration and checkout activities associated with the ground opera- 
tions for each flight consist of two major sets of tasks: (1) support 

functions, and (2) test and operations. The first set of tasks pertains to 
the operations analysis, requirements definition, system design, and inter- 
face hardware fabrication activities. The second set of tasks pertains to 
the installation, test, handling, and transportation activities associated 
with the actual processing of the flight hardware, and the associated GSE 
and special test equipment. 

In this section, the support functions are definitized and the optimiza- 
tion approach for the accomplishment of these functions is delineated. Test 
and operations activities are definitized in a subsequent section of this 
report. 

The complete Spacelab integration and checkout WBS, developed in Volume 
I, is used to graphically illustrate which elements of that WBS are support 
functions. The optimization of the conducting of the support functions tasks 
is presented in the second part of this section. Use of software is empha- 
sized. Responsibility criteria are established that maximize Pi/user 
involvement throughout ground operations, and minimize responsibility 
transfers and corresponding documentation requirements. 


i 
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3.1 DEFINITION OF SUPPORT FUNCTIONS 


In order to facilitate the definition of support function resource 
requirements, the functions were defined in three classes of activity: 

(1) mission-unique, (2) sustaining, and (3) non-recurring. The first class 
pertains to those activities that must be accomplished for each and every 
mission; they are repeatable and can be considered directly attributable to 
the ground operations associated with an individual Spacelab payload. Sus- 
taining activities encompass administrative, management, and institutional 
base support functions that are relatively independent of flight rate and/or 
individual Spacelab payloads. Non-recurring support functions pertain to 
those activities that adapt an operational Spacelab/Shuttle to the specific - 
requirements of a user. Each class of support functions is defined in this 
section. 

MISSION-UNIQUE SUPPORT FUNCTIONS 

Figure 3.1-1 presents the composite work breakdown structure (WBS), 
developed in Volume I, for integration and checkout of a Spacelab payload. 

Those activities that are not mission-unique support functions have been 
lined out. Since detailed descriptions for each WBS entry are presented in 
Volume I, only a summary of the mission-unique support functions are pre- 
sented here. 

Program Operation Support (20-00-00-00) 

The support services included in this WBS group include all non-personnel 
cost items. Travel and per-diem expenses for engineering liaison and mission 
support, as well as packaging and shipping charges associated with the trans- 
fer of flight hardware between processing centers, are included as part of 
Logistics (20-10-00-00). The effort and materials associated with editing and 
production of required documentation are included in the 20-20-00-00 entry. 
Engineering effort to develop the technical content of the documentation is 
not included in 20-20-00-00. Only machine (computer) run time is included in 
the Autocomputation entry (20-30-00-00). Procurement of material for inter- 
facing hardware is included m 20-40-00-00. Neither the design nor the fabri- 
cation of the hardware is included. Also, the procurement of Spacelab and 
experiment equipment are excluded from 20-40-00-00, as this WBS is applicable 
only to integration and checkout; it is not a programmatic WBS. The technical 
effort associated with these support services is included in the other mission- 
unique WBS task groups discussed in subsequent paragraphs. 

Mission Analysis and Planning (30-00-00-00) 

The tasks of this WBS group pertain to the engineering effort to investi- 
gate, analyze, and correlate various mission factors to achieve a mission 
plan that is compatible with experiment objectives and Spacelab/Shuttle capa- 
bilities. The factors to be considered include alternate flight trajectories, 
ground truth site requirements, expendable resources, and Shuttle and payload 
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specialist crew timelines. The basic products of the tasks in this WBS group 
are mission operational requirements and procedures, training plans, and 
(upon completion of this mission) analyses and reporting of mission accomp- 
lishments . 

Mission Operations (40-00-00-00) 

All the activities of the WBS group pertain to ground support of the 
flight. Real-time mission support at Shuttle, Spacelab, ground truth site, 
and user operations control centers is included. 

System Engineering (50-00-00-00) 

The tasks of this WBS group encompass the effort to convert mission and 
operations requirements into a system design. The effort includes both inter- 
face hardware design and software development/validation . Development of 
expendables, thermal, and power profiles that reflect planned experiment activ- 
ities and operations are included. Where applicable, form-and-fit mockups and 
training aids are designed and fabricated within this group of tasks. Both 
reliability and safety evaluations are conducted in conjunction with the Pi's. 
Combined experiments, Spacelab and Orbiter operations are considered in the 
system engineering effort. Determination and control of the center of gravity 
and weight of the integrated payload as well as the configuration management 
of all the involved flight hardware is also accomplished as part of this task 
group. 

Experiment Installation and Checkout (60-00-00-00) 

Mission-unique support functions in this task group are limited to the 
fabrication of interface hardware and preparation of Level III integration 
(checkout) procedures and reports. The actual assembly and test of experiment 
equipment, interface hardware, and Spacelab equipment is also included in this 
task group but is discussed as part of test and operations activities. 

Spacelab Integration (63-00-00-00) 

Since the interfaces at the Spacelab integration (checkout) level are 
to be standardized, only the preparation of test procedures and reports are 
considered to be miss ion- unique supporting functions in this WBS group. 

Orbiter Cargo Integration (66-00-00-00) 

In addition to the preparation of test procedures and reports, the 
coordination and reviews required to establish, the flight readiness of the 
Shuttle/Spacelab/payload are also included as part of the support functions 
of this WBS group. 

Ground Support Equipment (70-00-00-00) 

It is anticipated that special GSE will be required for the installa- 
tion and checkout of experiment equipment. In general, all unique electronic 
equipment is assumed to be furnished by the Pi's; however, stands, supports, 
slings, etc., to position/hold the Pi's electronic equipment (because of 
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the physical constraints imposed by the assembled equipment) will be required. 
The design and fabrication of this mis si on- unique handling equipment is the 
support function task in this WBS group. 

SUSTAINING SUPPORT FUNCTIONS 

The principal characteristic of all the sustaining support functions is 
that they are of a continuous nature. These activities are relatively independ- 
ent of flight rate and pertain to the accomplishment of the entire program 
rather than a specific flight. 

Only that portion of the integration and checkout WBS that is applicable 
to sustaining support functions is indicated in Figure 3.1-2. Program Manage- 
ment (10-00-00-00) is included in this support function class because the 
activities of this WBS group pertain to the administration (Cost and Perform- 
ance Management) and management (Project Direction) of the integration and 
checkout of a Spacelab payload, or the operation of the NASA centers involved 
(Institutional Base). 

Although the Advanced Experiment /Miss ion Definition (10-30-00-00) and 
Experiment Development Management (10-40-00-00) activities are not specifically 
part of integration and checkout, they were included in this WBS to emphasize 
the required interrelationship of the various facets of a continuing Spacelab 
payload program such as the ATL. 

# 

The Payload Specialists (40-40-00-00) are considered to be part of the 
sustaining effort. These members of the flight crew will probably be princi- 
pal investigators or personnel specifically trained to operate experiments in 
space. Their activities will encompass more than just the integration and 
checkout facets of a Spacelab payload program. Thus, these personnel and 
their associated effort are considered to be a staff function. 

Experiment Discipline and Project Engineering activities (50-70-00-00) 
are considered to be staff efforts. Discipline specialists will provide the 
interface between experiment development activities and integration and check- 
out activities. These activities will be a continuing effort that spans 
proposed, planned, and in-process payloads. Although project engineering can 
be identified with a specific mission, its primary function is to manage and 
direct the integration and checkout activities of all the line organizations. 

Equipment Maintenance (70-20-00-00) and Site Maintenance/Revalidation 
(75-30-00-00) encompass the periodic servicing, repair, and calibration associ- 
ated with the electrical and mechanical ground support equipment and facilities 
used in test and operations activities. General site maintenance (cleaning, 
painting, etc.) is not part of those two WBS items; it is included in the 
institutional base. 

NON-RECURRING SUPPORT FUNCTIONS 

Hie non-recurring support functions consist of those activities that are 
necessary to adapt an operational Shuttle/Spacelab to the specific requirements 
of a user. It is assumed that a basic data pack that provides ground rules 
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and guidelines for the integration and checkout of payloads will be formulated 
as part of the development of an operational Shuttle/Spacelab system. But the 
broad spectrum of users will have diverse application requirements. For 
example, each user will be required to develop logistics plans, repair/refurb- 
ishment/inspection procedures, and GSE and facility requirements that are 
commensurate with the physical and procedural constraints of the user center 
and reflect the planned flight rate of the user. 

Non-recurring support function tasks were intentionally grouped with 
mission-unique support function tasks to reflect the potential for continuity 
of effort. The non-recurring tasks are included in three WBS groups as 
indicated in Figure 3.1-3. All but two of the tasks are included within 
System Engineering. 

The non-recurring tasks consist of four types of activities: (1) flight 

hardware processing, (2) design guidelines, (3) design characteristics, and 
(4) processing accommodation at the user's site. Each type of activity and 
the associated WBS tasks are defined in subsequent paragraphs. 

Flight Hardware Processing 

Logistic Plans (20-10-00-00) for the shipment of experiment equipment and 
Spacelab flight hardware must reflect geographical location of the user and 
the physical constraints and capabilities of a user's site. Intra-site 
handling, loading, and transporting of Spacelab equipment to/from the departure 
point (usually an airport) will be unique at each user's site. 

Although maintenance schedules for Spacelab equipment are assumed to be 
established as part of the Spacelab development effort, flight rate and 
Spacelab configurations of each user will vary. Also, some experiment equip- 
ment will require special handling or may be utilized on successive flights. 
Thus, each user must develop a Turnaround and Refurbishment Plan (50-20-20-30) 
that is tailored to the planned usage of the flight hardware. 

A corollary to this requirement is the development of Repair and Refurb- 
ishment Software (50-30-20-40) to analyze and evaluate equipment performance 
data. Trends in performance/capability must be established to define timely 
maintenance/ repair /ref urbishment action. 

Design Guidelines 

Basic Shuttle and Spacelab payload accommodations will be provided to 
the user and will include generalized guidelines for experiment equipment 
design. But the broad spectrum of disciplines and experiment equipment that 
will be included in Spacelab payloads precludes direct application of these 
guidelines by a Spacelab user. Each user will be required to develop 
Experiment Design Criteria (50-10-10-40) tailored to the objectives, mechan- 
izations, and equipment of his program. 

Reliability Plans and Specifications (50-40-1 0-00) could vary signifi- 
cantly between payloads. In some cases, on-board spares /repair may be 
practical; multiple flights with the same equipment may be planned; or tech- 
nology limitations may restrict the equipment design. 
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It is recognized that stringent safety requirements will be imposed by 
both the Shuttle and the Spacelab to ensure both personnel safety and Shuttle/ 
Spacelab integrity. But unique Safety Standards and Criteria (50-50-10-00) 
will be required from each user that reflect the peculiarities of his experi- 
ment equipment. Fluids, test specimens, and radiation sources that may be 
used in advanced technology experiments will require the establishment of 
unique safety controls to be used during both ground and flight operations. 

Payload mechanization will vary between users and between Spacelab config- 
urations. Some experiments will, by their very nature, require automated 
operation. Experiment equipment mounted on pallet sections must be remote- 
controlled. Wire harness limitations will impose the requirement to use the 
Spacelab data bus /remote acquisition unit capability. All of these character- 
istics imply the use of software for experiment operation. Although the 
software may be unique from flight to flight. Test and Validation Software 
(50-30-20-50) can be standardized to expedite the integration and checkout 
activities. 

Design Characteristics 

Operational compatibility between the payload, Spacelab, and Orbiter is 
just as essential as equipment compatibility. Each user program will have a 
set of objectives that reflects the user's expertise and field of research. 
Operating modes and equipment characteristics will correspond to each user's 
unique experiments. Thus, Operating Instructions (50-20-10-10) and Equipment 
Specifications (50-20-10-20) that are tailored to the individual user's pro- 
gram are required. These activities must convert the generalized instructions 
for operation of Orbiter and Spacelab equipment and, specifically, common 
payload/multi-mission support equipment, to the planned application with user 
experiments. Specifications must reflect the specific design interface between 
experiment equipment and Orbiter/Spacelab equipment to control the design and 
development of experiment hardware. 

In addition to the controls on the operation and design of the experiment 
hardware, control of other interfaces with standardized Orbiter/Spacelab equip- 
ment is required. It is essential that both operational and hardware compat- 
ibility with these two higher levels of assembly is assured. Formal Interface 
Control Documents (50-20-30-00) are required to assure this compatibility for 
both ground and flight operations. 

Processing Accommodations at the User's Site 

General requirements for GSE and facilities for the Spacelab will be 
generated as part of the development of an operational Spacelab. But the 
existing accommodations at each user site will be unique. Also, user program- 
matic planning will vary. One user's plan may exhibit a slow rate of growth 
in the planned number of flights per year; another user may plan for a rapid 
growth rate or even discrete steps in flight rate. Thus, each user must 
develop GSE and Facility Requirements (50-10-40-00) that reflect existing 
capabilities and programmatic planning. Site Activation (75-20-00-00) plans 
must also correspond to the user's programmatic approach. 
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3.2 OPTIMIZATION OF SUPPORT FUNCTION TASKS 


The approach developed in this study to accomplish the support function 
tasks is delineated in this section. The preferred approach to accomplish 
miss ion- unique tasks associated with mission analysis and planning, mission 
operations, and systems engineering is presented. The principal investigator's 
role and responsibilities m the accomplishment of these tasks are also identi- 
fied. Where applicable, the use of software to accomplish these tasks is 
indicated. Responsibility criteria were developed to define the interrelation- 
ships between involved centers for each candidate processing concept. 

Instead of attempting to develop a technique for the accomplishment of 
each sustaining support function, an organizational approach which would 
encompass all the tasks, was selected. Center and organizational interrelation- 
ships are clearly defined by this approach. 

Accomplishment of non-recurring support function tasks are dependent upon 
the Spacelab user's program plan. Funding and schedule constraints will be 
the primary drivers in the specific technique to accomplish the tasks. The 
recommendation is made to plan non-recurring support function tasks as the 
initial effort of a systems engineering organization. 

APPROACH TO MISSION-UNIQUE SUPPORT FUNCTIONS 

In order to establish a preferred approach for the accomplishment of 
mission-unique support functions to be performed by a user, IC, and/or LS, 
the role and responsibilities of the principal investigators (PI) must first be 
defined. A clear definition of what is expected of the Pi's will then permit 
the def initization and optimization of mission analysis and planning opera- 
tions, and systems engineering activities of the experiment or payload 
integrators . 

Principal Investigator's Role and Responsibilities 

Each experiment consists of a unique sensor(s) supplemented by support 
instrumentation including specific display, processing, and control equipment. 
These equipments and the associated procedures for use, handling, packaging, 
and installation in standard racks, support canisters, or on pallet segments 
are delivered to the experiment integrator. It is the responsibility of the 
PI to design, develop, and performance test the experiment equipment. Some 
of these PI activities are completed prior to the initiation of integration 
and checkout activities definitized in this study. 

The i Pi's must provide a documentation data package for each experiment 
to enable the experiment integrator to perform the mission-unique support 
functions. This data package must include a hazards analysis, measurement and 
command list, display nomenclature, support requirements (power, cooling, data 
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storage, communications, etc.)» mission profile requirements (viewing angles, 
ground targets, truth sites, trajectories, etc.), and payload specialist 
requirements (set-up, calibration, operation procedures and timelines). The 
experiment integrator will, in turn, combine the data package for all experi- 
ments of a Spacelab payload into a composite/integrated/compatible flight plan. 

The PI must demonstrate the operability of his experiment equipment in a 
simulated flight configuration prior to actual installation in/on Spacelab 
equipment. To facilitate this demonstration the experiment integrator will 
provide to the PI the cabling, supports, mounts, adapters, and equivalent 
support provisions (power, cooling, data recording, etc.). 

The selection of the payload specialist members of the flight crew is 
the joint responsibility of the Pi’s and the experiment integrator. Ideally, 
the Pi's would be the payload specialists. In reality, this would be the 
exception for the following reasons. 

1. The number of payload specialists that can be accommodated 
in the Orbiter is four; there are several disciplines 
involved (in the ATL) , each with several experiments on 
any one flight. 

2. Generally, the term "PI" is used collectively; several 
associated individuals, each interested in a different 
aspect of an experiment, are involved. 

3. The PI is responsible for ground truth site activities 
during the mission as well as on-orbit activities. The 
PI must manage the entire operation — not just operate the 
equipment. 

Note that a particular PI being a payload specialist is not precluded. But 
it is presumed that a cadre of discipline specialists that have also been 
trained in space-flight operations will be established as a support group 
that will provide the required payload specialists for each flight. 

The cadre of payload specialists must receive training in the operation 
of the Pi's equipment, and develop a rapport with the Pi's in order to 
effectively and efficiently achieve experiment objectives. This training is 
also the responsibility of the Pi's and will be accomplished at both the 
individual experiment level and the integrated payload level. The payload 
specialists for a given flight will work with the Pi's in their laboratories 
during prototype hardware development and initial mission planning activities. 
The operators during individual experiment acceptance tests, installed experi- 
ment testing, combined experiment testing, and integrated Spacelab testing 
are the Pi's and/or the payload specialists. In this manner, the Pi's are 
directly involved throughout the processing of the flight hardware and the 
payload specialists are developing familiarization with the equipment, 
objectives, and procedures of the experiments as well as training with the 
actual flight hardware. This training approach also eliminates the need for 
complex and costly mission simulators. 
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It is believed that this approach to the roles and responsibilities of 
the Pi's will facilitate the integration and checkout of Spacelab payloads; 
maintain the direct involvement and experiment responsibility of the Pi's; 
ensure compatibility of flight hardware; and provide payload specialists who 
are acceptable to and trained by the Pi's, in the least expensive and most 
effective manner to fulfill the requirements of a Spacelab payload program. 

Payload Integrator Responsibilities 

It is the responsibility of the payload integrator to perform the mission- 
unique support functions — i.e., to provide the liaison and coordination between 
PI mission objectives and flight hardware, and the accommodations and capabil- 
ities of the Spacelab and Orbiter. Although the center primarily responsible 
for payload integration varies between processing concepts analyzed in this 
study (i.e., user in Concepts IV, V, VIII; IC in I, II, and VII; and IC and 
user in III "and VI), the basic support function tasks are the same regardless 
of concept. The preferred approach to these tasks (mission analysis and 
planning, mission operations, and systems engineering) is discussed herein. 

The interfaces between involved centers are discussed subsequently. 

Mission Analysis and Planning 

Mission analysis and planning requires the investigation of a large number 
of peripheral but interrelated factors pertaining to a flight plan to select 
an optimum combination that will maximize the usefyl results of a mission. 
Included in these factors are trajectory correlation to on-orbit and ground 
truth site activities, view angles, target resolutions, target lighting, 
payload specialists and composite flight crew scheduling, and attitude or 
pointing profiles. The analyses to correlate all of these factors are an 
iterative interaction process that is modified and refined to an eventual 
flight plan definition. 

Traditionally, mission analysis and planning requires a great deal of 
unique expertise in a variety of skills, plus some one individual who can 
integrate and evaluate tradeoffs that have no quantifiable functional rela- 
tionships. Thus, it would require a large number of highly specialized 
personnel for a relatively short time.. 

An alternative is to subcontract this effort to a NASA center that has 
had similar previous experience. This center might provide this service to 
many users concurrently. A significant disadvantage is that the Spacelab 
user would have minimal control over the tradeoffs, and a relatively long 
time delay would occur between iterations. Only the user can judge the 
tradeoff relationships and initiate meaningful alternatives. Therefore, he 
must become knowledgeable about all these factors. On this basis, the time 
delay between iterations becomes an intolerable constraint. 
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An option that could relax this constraint is possible. The mission 
analyst does not have to be an expert in orbital mechanics to obtain a 
trajectory plot. The algorithm and computation capability already exists as 
we 11- developed computer software. By entering initializing and boundary data, 
and calling for this (or other) program, a computer can print or plot the 
relevant information. Thus, a remote terminal at the user's location, tied 
to another center's computer, could provide a rapid turnaround. This option 
has two impacts : (1) whether the other center would make its computer avail- 

able as a time-shared processing complex to all users, and (2) the cost of 
leasing landlines between this center and all users. There is then the ques- 
tion of how many different programs (ground truth site look-angles, aircraft 
paths, crew timeline scheduling) could be available from one service center 
or, conversely, how many tielines to how many different service centers are 
needed? The complexity increases geometrically with the number of concurrent 
users. 

There appears to be no rationale to justify a vast interlocking multiple 
time-shared network. The programs (software) are portable and easily dupli- 
cated. All users have several large and identical (or at least compatible) 
data processing centers, so a trajectory program developed by JSC could be 
adapted to run on Langley's computer. The same can be said for other specialty 
programs (i.e., ground truth site scheduling, ground traces, expendable pro- 
files, etc.). With this approach, all the needed software (applications 
programs) are available to a broad spectrum of Spacelab users, are accessible 
on a short turnaround basis, and can be reiterated as needed with only the 
user's data processing center running time as a recurring or mission-unique 
cost. 

In addition, if the user's data processing center is configured as a 
time-shared multi-programmed service, with remote terminals in convenient 
locations, the operating cost would be further reduced. Such complex calcu- 
lations as plotting the subsatellite ground trace and ground truth site view- 
ing opportunities become no more difficult than using a pocket calculator. 

The development of activity schedule optimization software, like Langley's 
Manned Activity Scheduling System (MASS), into interactive (i.e., man-directed), 
conversational language tools, would enhance the applications-oriented 
mission analysis effort. 

It is recognized that some non-recurring costs will be incurred in the 
adaptation/initialization of applications programs at various user centers. 

But, these non-recurring costs will be significantly less than those that 
would result if each user developed his own applications program library. In 
fact, if the proposed sharing of applications programs is not adapted, it is 
doubtful if Spacelab users would develop their own. The tasks would either be 
performed with a laboriously manual technique, or sublet to other centers with 
the resultant unacceptable time delay between iterations, which was discussed 
previously. 
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Mission Operations 

The control of a mission is a combined and cooperative activity from 
launch through touchdown. The LS is the director of launch and landing oper- 
ations; post-launch (launch tower clearance), on-orbit, and entry operations 
of the Shuttle/Orbiter are monitored and directed from the Mission Control 
Center (MCC) at JSC; flight data dissemination is the responsibility of GSFC; 
on-orbit experiment operations are monitored and controlled by the Spacelab 
user in conjunction with the Pi's; and monitor and control of the Spacelab 
systems is concept-dependent. The first three segments of mission control 
(LS, MCC, and GSFC) are being planned and developed to support the entire 
Shuttle traffic model. The last two segments are of specific interest to 
this study and will influence the composite mission control approach. 

User-PI Mission Support . Monitor and control of on-orbit experiment 
operations by the user-PI will require real-time down-link and up-link 
communications to evaluate on-going activities and experiment data in order 
to advise (or redirect) the payload specialists and to coordinate all ground 
truth site activities. A mission support facility is required to provide 
these services. 

For Spacelab payload programs such as the ATL, the mission support facil- 
ity should be at the user center. The ATL's broad spectrum of experiments 
and numerous Pi's involved, plus the multi-f light-per-year/long-duration 
program preclude the approach of sharing a general-purpose /common-usage 
Spacelab payload monitoring center. Also, access and proximity to the Pi's 
laboratories are essential for two reasons: (1) the PI need not relocate 

for the duration of the mission; and (2) the PI may be able to simulate/dupli- 
cate contingencies m his lab that may arise during a mission, and devise 
work-arounds/solutions to these contingencies. The proposed proximity of 
the mission support facility would permit the Pi's to either be in attendance 
only during the operation of their experiments or be "on call" in case of 
contingencies. Real-time mission planning can be more readily and effectively 
accomplished if a mission monitoring/control facility is located at the 
Spacelab user center because of the Pi's direct access to mission data and 
the proximity of their labs. 

In this study, the mission support facility at the user center is referred 
to as the Operations Control Center (OCC). The key features of the OCC are 
active displays of factors that influence the mission. A simulated real-time 
and projected-time ground-viewing circle that follows the Orbiter ground track 
and has ground track site locations, aircraft flight patterns, cloud cover, 
etc. , superimposed on the display is recommended. Control and display con- 
soles for real-time, quick- look data reduction and display are also recommended. 
Direct voice and television communications between the OCC and the payload 
specialists are also included. This capability, coupled with the previously 
defined capabilities associated with mission analyses and planning activities 
will facilitate the direct participation of the Pi's in the flight and, if 
necessary, permit effective re-planning during the flight. 


3-15 


SD 74-SA-0156 


Space Division 

Rockwell International 


It is recognized that the Pi's and user center cannot accomplish mission 
monitor and control autonomously. Direct and continuous communication with 
the other involved control centers is required. Communications links with 
the MCC at JSC and, where appropriate, the operator of the Spacelab systems 
are also required to integrate both crew activities and utilization of 
Orbiter/Spacelab resources. At least one representative of the user center 
is stationed at non-user mission support centers for the duration of each 
flight. 

Spacelab Systems Mission Support . Except for Concept V, the Spacelab 
support systems are the responsibility of a center other than the user. In 
Concept I, the integration center is the owner/operator of the Spacelab sys- 
tems; in the remaining concepts, the LS is the owner/operator. The Spacelab 
support systems functions would be included in the OCC for Concept V. It is 
assumed that in Concept I a mission support facility would be at the integra- 
tion center. In the remaining concepts, it is assumed that the Spacelab 
systems mission support would be co-located and integrated with the Shuttle/ 
Orbiter mission support at JSC. 

Mission Data Dissemination . The currently defined technique for relaying 
data between the Orbiter and the ground during a flight is via a Tracking and 
Data Relay Satellite (TDRS) system. Depending upon Orbiter altitude, almost 
continuous communications can be achieved with only one receiving/transmitting 
ground terminal. The proposed ground terminal of the TDRS is at White Sands, 
New Mexico. 

Communication between the TDRS ground terminal and the various users of 
the Orbiter and the Spacelab is currently being studied by GSFC. If communi- 
cations are only required between the TDRS ground terminal and JSC, a dedicated 
microwave link could be considered. But the dispersion of Shuttle and Spacelab 
users precludes microwave links and/or leased lines (bandwidth-dependent) from 
the TDRS ground terminal to all potential users because of the agency costs 
involved. 

It is anticipated that during the Shuttle era, domestic geosynchronous 
communications relay satellites (DOMSAT) will be in operation. Preliminary 
evaluations indicate that it is feasible to relay flight data from the TDRS 
ground terminal via a DOMSAT to all potential users and the Orbiter/Spacelab 
operators in the Continental U.S. This data transfer can be accomplished by 
using only one DOMSAT transponder channel. Current planning indicates that 
the monthly lease' rates would be of the order of $40 thousand and would be 
the least costly from a mission-unique or recurring standpoint. Installation 
of DOMSAT ground terminals at user sites must also be considered. 

As the final flight data dissemination technique must reflect the require- 
ments of all participants of the Shuttle/Spacelab programs, techniques other 
than use of a DOMSAT may be adopted. But, for purposes of this study, it is 
assumed that the DOMSAT approach is practical and compatible with the require- 
ments of the operators and users of the Shuttle and the Spacelab. 
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System Engineering 

The preferred approach to support function system engineering tasks is 
based upon computer-aided analysis, design, and recordkeeping. The def ini- 
tiation of the accommodations and capabilities of the Orbiter and Spacelab 
during their operational era will permit the standardization and, thus, the 
computerization of significant portions of the system engineering tasks. 

System Requirements and Analysis . Standardized formats for the identi- 
fication of experiments requirements can be developed. Performance require- 
ments such as on/off cycles, power and cooling, data management, command and 
measurement lists, and operating instructions for common payload support can 
be synthesized m a format that will facilitate computerized compilation and 
integration in a manner similar to the integration of the composite on-orbit 
payload specialist activities by the MASS program. Experiment electromagnetic 
radiation characteristics that are required to evaluate potential EMI problems 
should be formatted such that computer-aided analysis can be accomplished. 

The Orbiter-cargo and integrated Spacelab checkout activities are relatively 
constant from flight to flight. The associated systems and interface verifi- 
cation test procedures can be standardized and, thus, these procedures can 
be computerized. 

System Design . Standardized rack and pallet accommodations permit the 
use of computers in determining and allocating equipment locations and vol- 
ume. Required view-angles and clearances should be included in the computer- 
aided design layouts. Automated wire lists and signal path routings should 
be developed. Mass and center-of-mass constraints of both the Orbiter and 
Spacelab will be well-defined to the user. A computer program should be 
developed which will compile payload mass characteristics, calculate the 
center of mass, and assess the compatibility of the payload with Orbiter/ 
Spacelab constraints. 

Systems Records . A significant quantity of system engineering manpower 
can be expended on the manual maintenance of test procedures, limits, docu- 
mentation, configuration management, and other recordkeeping functions. 
Although all of these items must initially be generated manually the changes, 
revisions, updates, additions, deletions, and substitutions can be more 
readily and cost-effectively accomplished by computerization. Wherever 
possible, all recordkeeping functions should be computerized. 

Mission-Unique Software Requirements 

Throughout the discussion of payload integrator responsibilities, the 
dependency upon automatic processors (computers) to accomplish the support 
function tasks in an efficient manner was emphasized. In addition to the 
utilization of computers in accomplishing support function tasks, computers 
will also be utilized in the conduct of the mission operations. Thus, soft- 
ware must be generated for each mission. The required/recommended mission- 
unique software and the approach to validation of the software are delineated 
in subsequent paragraphs. 
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Software Classifications , 

Eight classifications of software associated with mission operations 
were identified. The potential applications of each of these classes is also 
indicated. The eight classes are as follows. 

1.0 FLIGHT OPERATIONS. This is the software resident in the on-board 
computer that performs the functions of command, control, and data 
handling. These functions may be automated (pre-programmed), semi- 
automated (crew-directed) or remote controlled (radio command). 

2. 0 CHECKOUT /PERFORMANCE MONITORING. This software is used to 
acquire engineering data, configuration status, comparison to pre- 
selected tolerance or conditions, develop caution/waming/advisory 
signals, etc. This software would be resident in the Spacelab 
on-board computer during flight, and may be resident in a ground 
computer during the test and checkout ground operations. 

3.0 FAULT ISOLATION DIAGNOSTIC. This software is similar to 
Category 2.0, but is much more extensive and much less automatic. 

Under nominal conditions it is retained in the ground data base 
and is only called when trouble occurs. Then, it may be applied 
on the Spacelab on-board computer (in flight) or by a GSE computer 
(on ground). While this may be well developed for the support mod- 
ule and other support subsystems, it is not recommended for 
experiments. 

4.0 TEST AND VALIDATION. This software is used to prepare, test, 
debug, and validate the three previous software classes. It would 
be resident within the computer that supports the preparation of 
the three classes of software. It also includes compilers, 
assemblers, translaters, interpreters, and the progr amm ing lang- 
uage itself. 

5. 0 ORBITER SUPPORT. This software is resident in the Orbiter 
computer to provide correlation data (navigation, orientation, 
etc.) to the Spacelab data handling operation upon demand. Also 
in this category are the Orbiter performance monitoring and 
caution/waming backup. 

6.0 REPAIR/REFURBISHMENT. This software is used to evaluate 
Spacelab telemetry data to predict what maintenance actions are 
required, including logistics and resource allocation. It is 
resident in the ground data base complex(es). This software 
should be well-developed for support systems, but it is not recom- 
mended for experiments. 

7.0 DATA REDUCTION. This software is used to sort, merge, record, 
print, or otherwise prepare the flight data for disposition to the 
principal investigators. It also includes the real-time reduction 
for mission control. Similar programs may be in several different 
ground-based computers. 
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8.0 DATA ANALYSIS. This software is used to analyze the raw experiment 
data and could include statistical or trend data calculations. This 
software is used during postf light activities, and may be resident in 
several ground-based computers but not in the Spacelab on-board computer. 

The development, test, and validation of the software is a significant 
factor in the integration cycle. The software related to experiments is a 
recurring cost — new software must be provided for every mission. The develop- 
ment, test and validation of fault isolation diagnostic and repair/refurbish- 
ment software for experiments is not recommended because of the variation of 
experiment equipment from flight to flight. But the remaining six classes 
of software are considered mandatory for efficient operations. Also, the 
development of the basic program for these six software classes need only be 
accomplished once, fission- unique variations can be accommodated within a 
basic program, but retest and validation will be required. 

Estimates for software development, testing, and validation run as high 
as $80 to $100 per statement (FORTRAN) for a typical memory-limited computer 
system. NASA (particularly JSC, KSC, and MSFC) has conducted intensive studies 
to determine more efficient and less costly techniques to develop software. 

The NASA recommendations from the studies, which are proposed for incorporation 
in the Spacelab integration process, are summarized below. The essence of 
these recommendations is characterized by developing tools, techniques, and 
architecture so that the ultimate user can prepare his own application program. 


1. The user-programmer should not need to be aware of the intimate 

details of how the computer works: The internal executive and 

operating programming should be adequate to select and allocate 
resources, direct traffic, and manage the machine configuration, 
and not lose anything. 

2. The programming language should be English:, Limited vocabu- 
lary and constrained syntax are acceptable but mnemonic 
operating codes must be minimized. 

3. The software shall be modularized: The data to be operated 

on should be separated from the instructions that sequence 
the operations. 

I 

A. Use a large memory machine: Shortage of memory space has 

been identified as a prime factor in elevating software 
costs. No software prepared in other than machine language 
can be efficient in memory space utilization — so more space 
is needed. 

5. Provide adequate diagnostic and editing programs: This is 

how you "debug" a program, and should be part of the purchase 
cost of the machine. 
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6. Perform the program writing, assembly, compilation and de- 
bugging on the actual machine. The use of emulators and 
translators, to make one machine act like another, adds to 
the cost and adds one more risk. 

7. Provide macro instructions (for example, a square-root 
function key) for complex internal routines. The emphasis 

is on English- common scientific notation — not mnemonic codes. 

Software Test and Validation 

All software is prepared in several steps. First, the individual routines 
and subroutines are written, which is a manual operation. These routines are 
coded and read into a computer. The computer has resident software that inter- 
prets the source code into assembly code. The assembly language coded routines 
are then compiled — i.e. , put together in the proper sequence — and reduced to 
the target machine language code. This "program tape" (or card deck) is then 
ready to load into the using machine. 

The "program" would then be tested and debugged. Additional software 
consisting of one or more test problems (with verifiable results), a diagnostic 
routine to determine what went wrong, and an editing routine so that what was 
wrong can be fixed are required for this operation. 

When all the fixes are in and the test problems run correctly, the revised 
program is recorded, printed, and documented. If this program is now loaded 
into the target machine and the same test problems (or actual situations) can 
be run correctly and accepted by the user, the program is considered "validated." 

The use of a source other than the payload integrator to test and validate 
software involves two transfers of responsibility, both entailing a risk of mis- 
interpretation. First, the user must educate the programmer in the intricacies 
and operating Idiosyncrasies of his experiments; and second, the programmer 
must educate the user on the capabilities, limitations, and constraints of the 
developed program. 

The recommended approach for the test and validation of ATL Spacelab soft- 
ware is shown in Figure 3.2-1, and is analogous to the procedures for Orbiter 
computer software. Appropriate language, compiler, diagnostic and editing 
tools are provided by the contractor as part of off-line computer procurement. 

The computer executive program, operating system and file management software, 
display format "skeletons," etc., are also provided. A variety of applications 
modules, selected control or computation algorithms, etc., are also available. 

The PI provides data modules to the payload integrator which customize 
the application modules to a specific function. The PI prepares his input on 
several standard format data sheets — typically, a measurement list, a proced- 
ural list, a telemetry list, a tutorial page, etc. 
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The payload integrator accepts these data sheets from each PI and uses 
them to assemble a first-cut tape wherein the experiment and associated sup- 
port subsystems are merged to one operating routine. This routine (applica- 
tions and data modules) is loaded into a simulator of the Spacelab Control 
and Data Management System (CDMS) along with the executive and operating 
system software, concurrent with the installation of that set of experiment 
equipment. 

In this approach, the "debugging" of the operating routine is accomp- 
lished during experiment installation and test; editing and modification 
(only the data module) is done on site by means of a real-time editor which 
is part of the test complex but not part of the CDMS. The validated data 
modules (one for each experiment) are then assembled (off-line) into a 
mission tape. A similar process would prepare the Spacelab "housekeeping" 
tape at the next level of assembly. 

This approach for the test and validation of Spacelab payload software 
minimizes the transfer of software requirements and responsibilities and 
also reduces the required number of validations. Control of the configura- 
tion of the CDMS simulator will virtually eliminate incompatibilities between 
the flight operations software and the flight hardware. 
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The other five applicable Spacelab payload software classes can also be 
tested and validated with this approach. In-flight checkout and performance 
monitoring software is an integral part of the flight software package and 
should be used during the testing of experiments. The real-time editing 
capability will permit rapid changes to limits and set-up/calibrate routines. 
Although the test and validation software is not directly applicable to flight 
operations, it will be used/tested/validated during the testing and integra- 
tion of experiment equipment. Data reduction and data analysis software can 
be evaluated by using the data from the tests with the CDMS simulator. 

Orbiter support software can be tested and verified in a manner similar to 
that illustrated in Figure 3.2-1. Instead of the CDMS simulator, an Orbiter 
simulator is used in conjunction with the Spacelab flight hardware. 

Support Function Responsibilities 

The basic responsibilities of each center were initially established by 
the assigned ownership of the modules/racks/pallets that was part of the 
differentiation between candidate processing concepts. These ownership desig- 
nations established the center responsible for the ground and flight opera- 
tions of each individual Spacelab flight element (SM/EM shell, rack/rack sets, 
systems igloo, and pallet). But the responsibilities for the interfaces 
between elements and integrated sets of elements were not part of the initial 
concept definition. Support function tasks include these interfaces and 
integrations and the responsibilities are concept-dependent. In order to 
develop the total support function manpower and personnel requirements for 
each center for each processing concept, responsibilities for the tasks that 
involve interfaces and integrations must also be established. 

As the same set of support function tasks is required regardless of the 
processing concept, then the effort required to perform the basic task is 
the same for all concepts. In the operational phase of a Spacelab payload 
program, each center (user, IC or LS) would be capable of conducting any of 
the basic support function tasks just as effectively as any other center. 

The delta task efforts that are concept- depen dent are a result of multiple 
center involvement in some tasks. Therefore, where applicable, primary, 
secondary and support responsibilities must be defined. 

Responsibility Criteria 

In order to identify the role of each center in support function tasks, 
responsibility criteria were established. These criteria are presented in 
Table 3.2-1. The two principal themes of the criteria are (1) maintenance 
of owner cognizance, and (2) configuration control. 

Owner Cognizance . Pi/user involvement is not only desirable, it is 
the most efficient technique to accomplish all integration and checkout activ- 
ities. The unique equipment in each flight is the experiment hardware. The 
associated expertise and the authority to approve or disapprove the integra- 
tion and checkout of the payload remains with the owner of the experiment 
equipment — the Pi/user. 
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Table 3.2-1. Responsibility Criteria 


DRIVER 

OWNERSHIP 

CONFIGURATION MANAGEMENT 


MINIMUM PI /USER INVOLVEMENT 

INTERFACE CONFIGURATION CONTROL 
BY OWNER OF NEXT LEVEL OF ASSY. 

C 

INSTALLATION SITE PROVIDES 


R 

WORKING CREW; USER PROVIDES 

STRUCTURE FOR CONTINUING ATL 

1 

T 

E 

PAYLOAD SPECIALISTS 

PAYLOADS 

FLIGHT OPERATIONS SOFTWARE 

MODULE OWNER PROVIDES HARDWARE 

R 

PREPARED BY EXPERIMENT 

MODIFICATIONS 

1 

INTEGRATOR 


A 


CPSE CONTROL AND INVENTORY BY 


GROUND TRUTH SITES OPERATED BY 
EXPERIMENT INTEGRATOR AND PI 

OWNER OF NEXT LEVEL OF ASSY. 


The working crew should be made up primarily of on-site personnel. Pro- 
cedures, equipment, maintenance cycles, etc., will vary from site to site. 
Therefore, the most efficient technique is to use the owners of on-site GSE 
and facilities. This approach does not preclude participation by personnel 
from other centers during the test and operations activities. The development 
of test procedures is included in support functions. Personnel that assist 
in the preparation of these procedures will frequently be from a center other 
than the center actually performing the tests. Representatives from the 
supporting center should be present during the tests. Also, the payload 
specialists, which may be the Pi's (equipment owner) or their representative 
(equipment operator) are an integral part of the test team and will be 
involved in all tests and operations. 

Because the most dynamic software requirements are related to experiment 
operations, the experiment/payload integrator must be responsible for the test 
and validation of the flight operations software. This software must reflect 
the composite experiment requirements. Since these requirements are developed 
by the experiment integrator, the implementation of the flight operations 
software must be under the cognizance of the experiment integrator also. 

This approach does not violate the concept of flight hardware ownership. 
Software is considered a deliverable end item just like any hardware end item. 
Therefore, software can be owned by one center and the flight computer can be 
owned by another center. 

Ground truth sites require an integrated coordination effort. Although 
the PI will stipulate his requirements and may even operate a truth site, the 
interrelationships and interdependencies indicate that the integrator of the 
experiment flight hardware also integrate the truth site activities. 


3-23 


SD 74-SA-0156 








Space Division 
Rockwell International 


Configuration Control . It is impractical for the owner of one level of 
assembly to control the interface with a higher level of assembly because each 
succeeding higher level of assembly of the payload/Spacelab/Orbiter is more 
standardized. That is, each higher level of assembly must be compatible with 
a broad spectrum of potential users. Changes at higher levels of assembly 
could impact other users that a lower assembly owner would not even be aware 
of. Responsibility for the configuration control of interfaces must be main- 
tained by the owner of the highest assembly level involved. 

Examination of a particular ATL payload may support a unique responsibility 
matrix. But tailoring the matrix to each payload would not only be costly, but 
also result in confusion. The matrix must reflect a constant/repeatable 
approach that can be readily understood and implemented by a broad spectrum of 
experimenters /users . 

Hardware modifications must be controlled by the owner of the equipment 
(experiments/SM-EM shell/ racks /pallet) for the same reason interface control 
must reside with the highest level of assembly involved. Only the hardware 
owner has the visibility to determine the potential impact of changes and, 
thus, must re tain /maintain configuration control of that hardware. 

It is anticipated that common payload support equipment (CPSE) will be 
made available to Orbiter and Spacelab users. This equipment is not normally 
included in the Orbiter/Spacelab , but compatibility has been demonstrated. 

The CPSE would include equipment such as oscilloscopes, spectrum analyzers, 
counters, tape recorders, and signal generators. It would be impractical for 
every Spacelab user to maintain an inventory of Orbiter/Spacelab compatible 
CPSE. Therefore, the configuration and inventory control of CPSE is the 
responsibility of the Orbiter/Spacelab owners. 

Key Interfaces 

The results of the application of the previously presented responsibility 
criteria to key integration and checkout interfaces are presented in Tables 
3.2-2 and 3.2-3. Primary, secondary, and supporting roles for centers involved 
in each interface are indicated. 

Support function interface responsibilities (Table 3.2-2) reflect the 
role of the IC as the experiment/payload integrator and owner of Spacelab 
hardware in Concepts I and II. In other concepts the user assumes the 
responsibility for experiment/payload integration. IC responsibilities in 
Concept III reflect the ownership of the racks and pallet. The role of the 
LS is always in a secondary or supporting capacity. Participation of the LS 
in mission planning and Orbiter software requirements definition reflect 
ownership /operation of the Orbiter by the LS. Participation of the LS in 
other support function interfaces reflect LS ownership of the Spacelab sup- 
port systems. The user is always responsible for the training of the payload 
specialist in conjunction with the payload integrator and/or the owners of 
the Spacelab hardware. 
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Table 3.2-2. Key Experiment Integration Support Function Interfaces 



MISSION 

PLAN 

OPER 

INSTR 

PI/CREW 

TRAINING 

GROUND 

SUPPORT 

SYSTEM 

ANALYSIS 

SYSTEM 

DESIGN 

ORB ITER 

SOFTWARE 

REQMTS 

CONCEPT 1 

IC/LS 

IC/U 

U/IC 

IC/U 

1C 

1C 

IC/LS 

CONCEPT II 

IC/LS 

IC/LS /U 

U/ IC/LS 

IC/LS/U 

1C 

1C 

IC/LS 

CONCEPT III 

U/LS 

U/LS/ 1C 

U/LS/ 1C 

U/LS 

U 

1C 

U/LS 

CONCEPT IV 

U/LS 

U/LS 

U/LS 

U/LS 

U 

U 

U/LS 

CONCEPT V 

U/LS 

U 

U 

U 

U 

U 

U/LS 


NOTE: = PR IMARY/ SECONDARY/ SUPPORTING 


Table 3.2-3. Key Experiment Integration Hardware Interfaces 



R/P 

MODS 

SM 

MODS 

CPSE 

EXPERIMENT 

INSTALL 

SPACELAB 

INTEG 

— 

CARGO 

INTEG 

SL-OPNL 

SOFTWARE 

CONCEPT 1 

1C 

(1C) 

IC/LS 

IC/U 

IC/U 

LS/IC/U 

IC/U 

CONCEPT II 

1C 

(LS) 

IC/LS 

IC/U 

LS/IC/U 

LS/IC/U 

IC/U 

CONCEPT III 

1C 

(LS) 

IC/LS 

U/IC 

LS/U 

LS/U 

U 

CONCEPT IV 

U 

(LS) 

U/LS 

U 

LS/U 

LS/U 

U 

CONCEPT V 

U 

(U) 

U/LS 

U 

U 

LS/U 

U 


NOTES: 

•-/-/- = PR IMARY/ SECONDARY /SUPPORTING 
• (-) = LITTLE IF ANY MODS OTHER THAN CPSE 


3-25 


SD 74 -S A -0156 






























Space Division 

Rockwell International 


Responsibilities for hardware interfaces directly affect the prepara- 
tion of test procedures and the configuration management of the payload/ 
Spacelab/Orbiter. The responsibility matrix for hardware interfaces (Table 
3.2-3) reflects the ownership of the flight hardware and/or the highest level 
of assembly involved. The LS has primary responsibility for Orbiter cargo 
integration in all concepts as a result of its ownership/operation of the 
Orbiter. Similarly, the LS has primary responsibility for Spacelab integra- 
tion in those concepts where it owns the SM. User and IC primary responsi- 
bilities also reflect flight hardware ownership. In addition, the center 
responsible for payload integration is reflected in the designation of the 
primary center for Spacelab software. In all concepts, the user is directly 
involved in all levels of integration. Responsibility for experiments is not 
transferred as the level of assembly progresses. This hardware responsibility 
is also reflected in the IC's role in the various levels of hardware integra- 
tion. 


Based upon the responsibility criteria and the designation of primary, 
secondary, and supporting roles of the center in support functions and hard- 
ware interfaces, manpower estimates for each task, each center, and each 
concept were developed. The manpower estimates for miss ion- unique support 
functions are developed in Volume III of the report. 

APPROACH TO SUSTAINING SUPPORT FUNCTIONS 

Initially, an attempt was made to identify specific management/adminis- 
trative tasks and responsibilities for the sustaining activities associated 
with the processing of Spacelab payloads. But the characteristics of the 
individual tasks are not amenable to the development of manpower estimates 
that can be attributed to the processing of a Spacelab payload. Also, manage- 
ment responsibilities include the direction of operations at a center other 
than just the integration and checkout of a Spacelab payload. Scheduling of 
sustaining activities is also impractical because these activities are con- 
tinuous and relatively independent of flight rate. Therefore, the approach 
selected to definitize sustaining support functions was to derive a manage- 
ment organization at each center that was tailored to the requirements of 
each processing concept. 

User Center Organization 

Figure 3.2-2 presents the derived user organizations for the processing 
concepts. Line organizations that report directly to the ATL Program Office 
include three principal activities: advanced mission/experiment planning, 

experiment development, and integration and checkout. Integration and check- 
out activities are expanded to reflect three major areas of effort: opera- 

tions analysis, systems engineering, and test and operations. Only managers 
and their secretaries are considered to be sustaining personnel. Lower levels 
of supervision are flight-rate dependent and directly attributable to the 
processing of a specific payload. Note that the test and operations organi- 
zation is not applicable for Concepts I, II and VII. All processing of 
flight hardware is performed at a site other than the user's site. 
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Figure 3.2-2. User Center Sustaining Organization 


A technical staff is indicated, which transcends both all the program 
activities and the line organizations. A cadre of payload specialists is 
indicated. These personnel will be involved in all facets of the ATL program 
and, thus, their contributions/time cannot be attributed just to integration 
and checkout. 

In addition, a cadre of experiment discipline specialists is identified. 
As the ATL program involves six major discipline/technology areas of endeavor, 
one individual was identified for each area. The role of the discipline 
specialists is to provide the liaison and coordination between experiment 
equipment development activities and integration and checkout activities. 

The one group of personnel in the sustaining organization that can be 
attributed to the processing of a specific payload is the flight project 
managers. The function of a flight project manager is to coordinate and 
direct all the effort at the user center to integrate and check out a pay- 
load; he is the representative of the program office for a specific payload. 
The flight project manager is also the primary interface with management 
from other involved centers. 

An administrative staff is also indicated for maintenance of programmatic 
records such as schedules and costs. 
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Integration Center Organization 

Figure 3.2-3 illustrates the organization at the integration center 
that is required to manage /administer the integration and checkout activities 
at that center. The line organizations are the same as those of the user 
center. This organization is applicable only in Concepts 1, II, III, VI 
and VII. (IC is not involved in IV, VIII and V.) In addition, the operations 
analysis line organization is only applicable in Concepts I, II, and VII. The 
user center assumes the responsibilities of this line organization in all other 
concepts. 



Figure 3.2-3. Integration Center Sustaining Organization 


A payload project manager is identified in a staff position. The role 
of this manager is essentially the same as the flight project manager of the 
user organization. It Is the responsibility of the payload project manager 
to direct and administer the required center resources to accomplish the 
integration and checkout of a Spacelab payload. One payload project manager 
is assigned/dedicated to each Spacelab payload being processed. 

Launch Site Organization 

The organization presented in Figure 3.2-4 reflects the launch site's 
role as owner/operator of the Orbiter in all concepts and, when applicable, 
the owner/operator of the Spacelab support module and systems igloo. Two of 
the line organizations are indicative of the two integration levels that occur 
at the launch site. Orbiter cargo integration is applicable in all concepts. 
Spacelab /payload integration occurs at the launch site in six of the eight 
candidate processing concepts. The procedures, GSE, and facilities associated 
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with these two integration levels will be significantly different. Therefore, 
separate line organizations were identified. 



•REPLACES CARGO PROJECT MANAGER IN 
CONCEPTS ll/VII, lll/VI AND IV/VIII 


The systems engineering line organization is indicative of the launch 
site in the accomplishment of support functions. Operations analyses, mission 
planning, requirements definition, and design and fabrication of interfacing 
hardware are the responsibility of centers other than the launch site. A sys- 
tems engineering line organization is required at the launch site to coordinate 
payload and cargo requirements and ensure compatibility between the payload, 
Spacelab, and Orbiter. 

As the role of the launch site varies between concepts, two types of 
project managers were identified. In those concepts where the launch site 
performs only Orbiter/cargo integration, a cargo project manager is identi- 
fied; in those concepts where the launch site performs both Spacelab/payload 
and Orbiter/cargo integration, a payload project manager is identified. This 
differentiation was established to avoid transfer of management responsibility 
at the launch site during the processing of a payload. The role of the launch 
site project manager is essentially the same as the integration center payload 
project manager and the user's flight project manager. That is, the launch 
site project managers will direct and administer the required center resources 
to accomplish the processing of the payload and Spacelab through that center. 
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APPROACH TO NON-RECURRING SUPPORT FUNCTIONS 

Development of an approach to accomplish the non-recurring support func- 
tions is dependent upon two factors : the program plan of the Spacelab user 

and the basic data pack that will be available from the Spacelab manufacturer 
(ESRO/ERNO) and operations developer (MSFC). Each Spacelab user will derive 
a unique program plan that reflects objectives, schedules, and funding con- 
straints. It is impractical to develop a generalized approach that will 
delineate phased activities to derive payload processing procedures, controls, 
software, GSE, and facility requirements. But the identification and defini- 
tion of the support functions that must be accomplished prior to initiation 
of integration and checkout operations will provide the visibility to the user 
to develop a tailored program plan. 

At the time of this study, the data pack to be developed by ESRO/ERNO and 
MSFC was in an evolutionary stage. Both the lists of documents, handbooks, 
software, etc., and the contents were changing. Therefore, based upon prelim- 
inary data from ESRO/ERNO and MSFC, assumptions were made as to the scope and 
detail of the data pack that will be available to the Spacelab user. The 
support function requirements to adapt the basic data pack to the unique appli- 
cations of a user are directly related to these assumptions. In order to avoid 
cross-referencing between volumes of this report, both the assumptions pertain- 
ing to the basic data pack and the non-recurring support function requirements 
are presented in Volume III. 

The only tangible recommendation to accomplish the non-recurring support 
functions is to perform the tasks with the nucleus of the systems engineering 
line organization that will participate in operational integration and checkout 
activities. This approach will facilitate a smooth transition from the develop- 
ment stage to the operational stage of integration and checkout. The synthesis 
of the WBS incorporated this approach. The WBS included the majority of the 
non-recurring support function tasks in the systems engineering group. 
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4.0 TEST AND OPERATIONS 


In this section the second major set of integration and checkout tasks, 
test and operations, are established, defined, and optimized. The optimized 
checkout approach included the establishment of guidelines that emphasized 
functional ground testing of flight equipment in the same manner as the 
planned flight operations. A computer-aided technique that would utilize 
the capability of the on-board data management system (DMS) of the support 
module /systems igloo was the preferred approach. 

The feasibility of the preferred checkout approach was evaluated in terms 
of the operational capability and the memory capacity of the DMS. Operational 
capacity was more than ample; additional mass memory (tape recorders) was 
required for reference data. 

Use of support system/interface simulators during Level III integration 
was evaluated. A negligible effect in experiment hardware processing time 
resulted. The complement of support modules /systems igloos required to 
support the anticipated Spacelab traffic model was significantly reduced by 
the use of simulators. All developments of processing concepts reflected 
incorporation of support system/interface simulators during Level III integra- 
tion activities. 

Three categories of checkout requirements were evaluated: functional, 

environmental, and operational. Functional checkout requirements for both the 
Orbiter/Spacelab and the experiment systems were evaluated. Only functional 
testing of experiment systems and interface verification testing of experi- 
ments/Spacelab/Orbiter were identified as being required. The environmental 
checkout requirements were evaluated by analyzing the trends in recent space 
programs in terms of their applicability to the characteristics of the ATL 
Spacelab program. This effort evaluated the anticipated ATL/Spacelab envir- 
onmental requirements and established a preferred verification approach. It 
was recommended that all integrated payload environmental certifications, 
except electromagnetic compatibility (EMC) be accomplished by analysis/simi- 
larity techniques; empirical tests were required only for EMC certification. 
Operational checkout requirements were analyzed in terms of the potential 
processing cycle impact of payload cleanliness constraints and shipping/ 
transportation modes. These two areas were evaluated because of their influ- 
ence on the test/ re test requirements as well as installation/assembly proced- 
ures and sequences. 

A composite set of test and operations requirements was derived and is 
presented in matrix format. The appropriate integration level, where the 
test/checkout requirement is satisfied, was also identified. 
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The three-step approach utilized to establish the detail flows is delin- 
eated in Subsection 4.2. The establishment of top-level functional block 
diagrams that reflect hardware processing scenarios of the test and operations 
activities for all eight processing concepts is presented. The expansion of 
these block diagrams to detailed flows and activity data sheets (presented in 
Appendix D) is illustrated. The time estimating technique for the detail 
flows and their utilization to define an integrated flow sequence is presented. 
The integrated flows for each concept are evaluated and the summaries of 
processing times compared. Based upon a single-shift five-day work week, the 
processing times of the candidate concepts are about six calendar months. 
Variations between concepts can be attributed primarily to handling/shipping 
requirements . 
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4.1 DERIVATION OF TEST AND OPERATIONS APPROACH 


The approach adopted for the accomplishment of the test and operations 
activities is a key factor m minimizing both the recurring and non-recurring 
costs of the NASA for integration and checkout of Spacelab payloads. Two 
interrelated considerations are the minimizing of processing time and the 
maximizing of the utilization of equipment. 

Checkout guidelines were established that emphasized the functional test- 
ing of the flight equipment in a manner analogous to the planned flight oper- 
ations. Unique ground testing was minimized. Use of the on-board data 
management system during checkout was evaluated. With testing limited to 
functional operations rather than performance or capability evaluation, the 
on-board system was adequate and facilitated simultaneous software /hardware 
verification. 

Use of simulators of elements of the Spacelab was evaluated. It was 
determined that the complement of required flight hardware could be signifi- 
cantly reduced with the use of simulators. Consequently, programmatic costs 
could also be reduced. 

Functional test requirements were defined that reflect the operational 
nature of the Spacelab and Orbiter. The mission-unique activities are associ- 
ated with experiment integration (Level III). Spacelab and Orbiter-cargo 
integration (Levels II and I, respectively) is relatively standard from flight 
to flight, and test activities should be limited to interface verification. 
Compatibility of interfaces was demonstrated during the operational develop- 
ment activities of these two programs. 

Environmental testing of integrated Spacelab payloads was minimized. 

Based upon the fact that the environments that Spacelab payloads will be 
subjected to will be firmly established, individual experiment equipment 
environmental testing was recommended; only analytical techniques were 
recommended for evaluation of environmental effects at the integrated payload 
level of assembly. The one exception to the analytical approach was with 
respect to electromagnetic compatibility (EMC). Empirical testing will be 
required to assure EMC. 

Operations considerations indicated that maintenance of appropriately 
clean environments during test and shipping/transporting activities will 
permit complete assembly and checkout of each level of assembly prior to 
mating with the next higher order of assembly. Last-minute installations 
and checkouts were minimized. 
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Use of the proposed 747 piggyback mode for transport of assembled 
Spacelab elements or the C-5A when only racks and pallets are Involved, pre- 
cluded the disruption of interfaces after verification. Retesting after 
major moves was limited to receiving-inspection type activities. 

A composite set of test and operations requirements was derived. The 
accomplishment of each requirement in the checkout sequences for the various 
candidate processing concepts was identified. 

OPTIMIZED CHECKOUT APPROACH 

Basic guidelines for the checkout of a Spacelab payload were formulated. 
The factors to be optimized were defined and the resulting provisions in the 
checkout approach were identified. Alternate implementation techniques were 
evaluated and a preferred approach selected. 

Checkout Guidelines 


The development of checkout guidelines is illustrated in Figure 4.1-1. 
These guidelines reflect a test philosophy that stresses the verification of 
planned flight operations. Off-nominal or limit testing to assess the capa- 
bility of equipment/systems should not be included in the integration and 
checkout activities of an operational program. 


OBJECTIVE 


OPTIMIZATION FACTORS 

VERIFY EXPERIMENT 


STRUCTURE FOR 

. SETUP 


. PI /CREW ORIENTATION 

. CALIBRATION 


. MINIMUM RETEST 

/ . OPERATION 


. ON-LINE FLEXIBILITY 


. Ml SS 1 ON-TO-MI SS 1 ON 


FLEXIBILITY w 




PRIMARY CHECKOUT PROVISIONS 


CHECKOUT OPNS SIMILAR TO FLIGHT OPNS 
INTEGRATED SOFTWARE /HARDWARE VERIFICATION 
INTEGRAL CHECKOUT/MISSION PROGRAM DEVELOPMENT 
MAXIMUM USE OF FLIGHT SOFTWARE 
ADAPTIVE PROGRAMMING APPROACH 


Figure 4.1-1. Checkout Guidelines 

The assembly and integration of the several elements of the Spacelab 
include several intermediate checkout points wherein the installation is ver- 
ified as being correct. These checkpoints start at the lowest integral 
assembly (the experiment) and progress through the rack/pallet and complete 
Spacelab to the Orbiter installation. The checkpoints should involve selected 
tests and operations performed to assure that all system elements achieve 
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experiment objectives. That is, the objective of the tests should be to 
demonstrate the capability to set up, calibrate, and operate the experiments. 

The accomplishment of this objective is dependent upon the compatible 
operations of several subsystems that will be managed and controlled by the 
crew and aided by the on-board data management system. At the experiment level 
of assembly, the following elements are involved: 

. Unique phenomena sensor . Payload specialist crewmen 

. Supporting instrumentation . Spacelab data management hardware 

. Supporting subsystems . Spacelab data management software 

Higher levels of assembly and installation require these same elements 
with other elements progressively added: 

. Rack and/or pallet equipment 

. SM subsystem provisions 

. Orbiter subsystem provisions , 

The several levels of assembly and integration will require a number of 
test operations. An optimum approach would be structured around the critical 
factors of (1) Pi/crew orientation, (2) minimum retesting, (3) on-line flexi- 
bility, and (4) mission-to-mission flexibility (see Figure 4.1-1). 

The payload specialists should know how to operate the experiment equip- 
ment (procedures) and understand the phenomena being investigated. The source 
of their orientation is the principal investigator (one or more) , and they 
would become familiar with the experiment by participating and operating the 
equipment at the Pi's facilities. 

In general, the payload specialists will have flown on previous missions 
(especially in the case of a continuing program such as the ATL) , and will be 
competent in the operation of Spacelab systems. The mission-unique orienta- 
tion will be the adaptation of the standardized Spacelab systems to command/ 
control the operations of a particular payload. The checkout procedures 
should be devised to provide this orientation. 

In past space programs, it was common practice to verify flight hardware 
operations with checkout software, and flight software with simulated hardware. 
Invariably, major incompatibilities occurred when the two end items of flight 
equipment were integrated. In Section 3.2 of this volume, a technique for 
parallel development of flight software and hardware that culminated in simul- 
taneous checkout and verification was delineated. The technique is proposed 
as a basic approach to optimizing checkout techniques. Serial test time is 
reduced, retest is minimized, and the associated support functions of test 
procedures preparations, test reports, GSE requirements, configuration control, 
etc. , are minimized. 

As the primary objective of checkout is to demonstrate the mission opera- 
bility of the systems, the checkout approach should reflect the planned mission. 
Checkout and mission development should not be discrete entities; they should 
be accomplished as an integrated set of tasks. One technique to facilitate this 
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integration is to utilize flight procedures and flight software wherever 
possible. 

Revisions to equipment, procedures, and software during the integration 
and assembly operations should be anticipated and reflected in the checkout 
approach. Capability for modifying the checkout approach should be included. 
Since a certain amount of the testing is controlled by the Spacelab data man- 
agement system software, the checkout approach should incorporate a quick- 
turnaround capability in software preparation. In Section 3.2 of this volume, 
the inclusion of a real-time editor in the checkout station GSE was recommended. 

Mission-to-mission flexibility is important to the achievement of low-cost 
multiple-mission operations. The checkout equipment, procedures, simulators, 
etc. , should be implemented by an approach that can match the flexibility of 
Spacelab experiment payloads without extensive rework between missions. 

Adaptive programming will provide the required flexibility both during check- 
out and between missions. 

The checkout approach model should provide for concurrent verification 
of software, hardware, procedures and interfaces to minimize both cost and 
time. The mission operations development and the checkout verification oper- 
ations should be synchronised and adaptable. Since the objective of checkout 
is to assure in-flight operations, then checkout is very similar to in-flight, 
and would take maximum advantage of the flight control software prepared for 
the Spacelab data management system. 

In addition to meeting the checkout objectives and guidelines, the check- 
out approach provides for on-line verification of the flight software. No 
on-line facility computer is required because the simulator with its flight- 
equivalent computer is used. 

The integral software/hardware checkout approach provides the opportunity 
to perform an abbreviated mission simulation. It is recommended that the pay- 
load specialist crew members (the Pi’s or their representatives) use the check- 
out operations as a mission training activity. In this manner, the payload 
specialists will be getting flight hardware and software experience. In a 
continuing program, such as the ATL, the payload specialists will probably 
have flown on previous missions and their experience will be invaluable during 
the checkout activities. 

Alternate Checkout Implementations 

As shown in Figure 4.1-2, three approaches to achieve the checkout guide- 
lines were evaluated. A manual approach would result in prohibitive in-process 
time. An automated approach would be very costly and would not meet several 
key goals in the checkout process. It would be of little use to the flight 
crew, and both on-line and mission-to-mission flexibility would be almost 
impossible to achieve. A computer-aided approach can be structured to meet 
all the checkout guidelines. 
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Figure 4.1-2. Alternate Checkout Implementations 

Use of the on-board data management system (DMS) of the support module/ 
systems igloo was evaluated to determine its capability to support the check- 
out of the support system and the integrated rack and pallet assemblies. 

(This evaluation is presented in subsequent paragraphs of this section.) 
Adequate capacity exists for such checkout and also integrated Spacelab 
checkout. Thus, the checkout software for the ATL/Spacelab can be incorpor- 
ated in the SM computer. Flight software can be concurrently developed and 
verified with the checkout software or flight-equivalent hardware. 

Use of the flight DMS during rack/pallet checkout is not recommended. 

The involvement times of the DMS, if it were used during Level III integra- 
tion, would significantly increase the required complement of these equipments 
to support the anticipated Spacelab traffic model. (The evaluation of the use 
of simulators versus flight hardware is presented in subsequent paragraphs of 
this section.) 

Special-purpose GSE/simulators were identified for both the DMS and the 
Orbiter interface. Use of general-purpose equipment in the simulators was 
rejected because of the problems invariably encountered when flight hardware 
is utilized at the next level of assembly and checkout. The recommended sim- 
ulators are flight hardware equivalent. Configuration control of the simu- 
lators must be maintained. In this manner, problems at the next level of 
integration will be minimized. 
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FEASIBILITY OF CHECKOUT APPROACH 

The selection of the preferred checkout approach was contingent upon the 
capability of the Spacelab data management system (DMS) and the practicality 
of the use of a DMS simulator during Level III integration. Both of these 
potential limitations are discussed in this subsection. 

Data Management System Compatibility 

Two aspects of the data management system requirements were evaluated: 

(1) operations, and (2) main memory. The capability of the DMS to accommodate 
the requirements was assessed. Checkout implications were defined. 

DMS Operations Compatibility 

At the initiation of this study, only one computer was included in the 
DMS. As of October 1974, three computers were identified: one for support 
systems, one for experiment operations, and an on-line spare for either of 
the other two. As the final configuration has not been established, a con- 
servative approach in the evaluation of DMS capacity was used. It is 
assumed that only one computer is available; therefore, the evaluation 
included estimating both support system and experiment system requirements. 

Support System Requirements . There are seven support subsystems within 
the Spacelab : 

1. Environmental Control Subsystem (ECS) 

2. Command and Data Management Subsystem (CDMS) 

3. Electrical Power and Distribution Subsystem (EPDS) 

4. Structure Subsystem 

5. Instrument Pointing Subsystem (IPS) 

6. Software Subsystem 

7. Common Payload Support Equipment (CPSE) Subsystem 

At the time of this study, none of the above listed subsystems were adequately 
defined to estimate the required measurements and commands to operate them. 

The basic design/operations approach to the Spacelab support systems closely 
parallels the approach adopted in the Phase B Modular Space Station (MSS) 
preliminary design. Therefore, estimates for Spacelab subsystems operations 
requirements were extrapolated from MSS data. 

The Modular Space Station was configured to support 6 or 12 men indefin- 
itely and autonomously; the Spacelab is configured to support 2 to 4 mean for 
7 days. Therefore, to be useful, the measurement and command estimates should 
be scaled down by a factor of 3 to 6. (MSS had six active habitable modules, 
each larger than the Spacelab.) Table 4.1-1 is a compilation of applicable 
MSS requirements. Table 4.1-2 presents the scaled-down estimates for the 
Spacelab. 
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Table 4.1-1. Space Station Measurements and Commands 


Subsystem 

Function 

Time Criticality 

Measurement 

Command 

Analog 

Discrete 

On-Off 

Settings 

EPS 

Battery/inverter 

1 second 

40 



4 


Battery charging 

1 second 

3.5K 

96 

1.5K 



Primary bus 

4 milliseconds 

4 

32 

56 

8 


Secondary bus 

1 second 

378 


42 

14 


SSCB 

100 milliseconds 

540 

540 

540 




1 second 

540 

540 

540 


ECLSS 

Pumpdown and 

1 minute 

10 

18 

10 



repressurization 







COp management 

1 second 

24 

16 

16 

2 


(D&S) 







O 2 partial 

1 second 

2 

2 


1 


pressure 







Humidity and 

1 minute 

26 

42 

34 

4 


contamination 







Circulation and 

1 minute 

90 


60 



tempera tu re 







control 







0 2 -N 2 control 

1 second 

49 

5 

16 

2 


Active thermal 

1 minute 

98 

77 

146 



EPS = Electrical Power Subsystem 
ECLSS = Environmental Control and Life Support Subsystem 


4-9 


SD 74-SA-0156 


















Space Division 
Rockwell International 


Table A. 1-2. Extrapolated Spacelab Subsystem Measurements 

and Commands 



gnu 

Measurements 

| Command 

Measurements 

Subsystem Function 


A 

D 

H 

n 

per 

Second 

EPDS Inverter 

1.0 

mm 



4 

10 

Battery pack 

1.0 


10 

20 


60 

Primary bus (28 vdc) 

0.1 

MM 

8 

8 


120 

Secondary bus 
(6 voltages) 

0.1 

H 

16 

32 


400 

Circuit breakers 

0.1 


20 

40 


400 

Circuit breakers 

1.0 

mm 

100 

200 


200 

ECS/ARS CO? management 

1.0 

24 

16 

16 


40 

O 2 partial pressure 

1.0 

2 

2 


1 

4 

Humidity and contam. 

60.0 

26 

42 

34 

4 

1 

Circulation and temp. 


90 

- 

60 


2 

O 2 -N 2 control 

1.0 

12 

•4 . 

8 

n 

16 

Coldplate 

60.0 

20 


20 

■ 

1 

Structure 







Stress/mountings 

60.0 

20 


20 


1 

Hatches, etc. 

1.0 



4 

1 

( 1 

20 

Subtotal 



• 


■ 

1275 

Inst. Pointing 





• 


Angles, etc. 

0.1 

12 

24 

24 

j 

360 

CDMS 







Auxiliary and 
peripheral 

1.0 

20 

20 

40 


40 

Total 


434 

302 

338 


1675 


EPDS - Electrical Power and Distribution Subsystem 
EC S/ ARS - Environmental Control Subsystem/Air Revitalization Subsystem 
“S - Instrument Pointing Subsystem 
CDMS - Control and Data Management Subsystem 
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There were no comparable estimates for the instrumenting pointing sub- 
system (IPS), the tunnel, or common payload support equipment (CPSE). The 
information management subsystem of the MSS included self-test capability by 
built-in software. It was assumed that the Spacelab CDMS would have compar- 
able capability. The tunnel measurements and commands were included within 
the structures estimates, and the CPSE was arbitrarily grouped with the 
experiment equipment. 


The IPS is a multiple-axis platform mounted on the pallet to handle the 
instruments requiring more precise pointing stability than the basic Orbiter 
attitude control system. Thus, it must sense, compute, and control motions 
based upon the Orbiter reference. It is believed that this control loop mech- 
anization will, because of the high iteration rate and double-precision 
computations, utilize a dedicated processor and not share the CDMS processor. 
Therefore, the assumption was made that checkout would require no more than 
the capability to command a selected attitude and measure a few outer loop 
parameters. These estimates are included in Table 4.1-2. Also, those status 
and on-off commands for CDMS auxiliary and peripheral equipment (e.g. , closed- 
circuit TV and recorders) were added. 

The operations estimates for Spacelab subsystems total 1675 measurements 
per second, and the total number of data points (sensors) is 736. The esti- 
mated number of commands is 338 (no rate). If 736 measurements and 383 com- 
mands are implemented by discrete, dedicated meters, lights, annunciators and 
switches the control panel will be very "busy", difficult to read, and expens- 
ive. For comparison, the Apollo Command Module main display console (3 panels) 
contained about 300 discrete components, and cost approximately $1.0 million 
per panel, per spacecraft. Therefore, the assumption was made that some form 
of multipurpose time-shared displays and control would be used, and discrete 
components would be limited to circuit breakers and clock-type displays. 

In order to accomplish the data acquisition and performance monitoring 
function, six operations are required: 

1. Request to data bus controller. 

2. Accept data bus controller data block. 

3. Fetch nominal, U.L., and L.L. values from memory. 

4. Compare actual to nominal, and limits. 

5. Store new value in memory block. 

6. Access new value, nominal, U.L, L.L. , and' nomenclature for 
display processor. 

The timing estimate for these operations, based upon a total of 736 
measurements, is given in Table 4.1-3. Preliminary definition of the CDMS 
computer(s) indicates that in excess of 500,000 operations per second can be 
accommodated. Thus, the extrapolated requirements for support systems oper- 
ations is about one percent of the computer capacity. The on-board CDMS is 
more than adequate to support the performance monitoring and thus the ground 
checkout operations of Spacelab support systems. 
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Table 4.1-3. Timing Functions 


Operation 

Microseconds 

1. Request to DBC 

2 

2. Transfer 736 words 

1,472 

3. Fetch 736 words 

1,472 

4. Compare 2 and 3 

1,472 

5. Store 736 words 

1,472 

6. Access 736 x 6 words 

4,416 

Total 

10,306 


Experiment Systems Requirements . The previous analyses demonstrated that 
the Spacelab CDMS could support the integrated checkout of Spacelab support 
subsystems using about one percent of the specified capability of the on-board 
computer. The estimates were based upon the extrapolation of Modular Space 
Station support system requirements. There was no comparable measurement/ 
command estimates for experiment systems. Therefore, two ATL experiments were 
analyzed to establish a probable measurement/command list. In both cases, 
about 30 discrete commands , and a similar number of measurements , were required 
to set up, calibrate and/or operate the system. 

The specific data pertaining to one of the experiments. Laser Ranging, is 
presented to illustrate the compilation of the requirements for an on-line 
Spacelab payload. Figure 4.1-3 illustrates the major assemblies of the Laser 
Ranging experiment. Table 4.1-4 is a list of operations that would be per- 
formed to set up, calibrate, operate and stow this experiment. Table 4.1-5 
is a list of the engineering measurements the operator would monitor. Refer- 
ence Payload 2, Appendix C, has 11 separate experiments. Utilizing 30 
measurements as the average complexity level for each experiment, then about 
330 measurements would be the estimate that the Spacelab CDMS must handle. 
Assuming that each measurement is sampled once per second, and that in normal 
operation, only one or two experiments are active concurrently, the support 
requirement is on the order of 60 measurements per second. 

This number is smaller than the estimate of 736 measurements for the 
Spacelab subsystems. Even if all experiments were monitored continuously 
(330 measurements), they would still be comparable. Therefore, we can conclude 
that the Spacelab CDMS computer can support the operations of both Spacelab 
subsystems and Spacelab experiments integration checkout requirements, and 
still have about 98 percent of its capability available for other purposes. 

DMS Memory Compatibility 

The analyses of the support systems and experiment system operations 
requirements indicated that the CDMS computer had more than sufficient capacity, 
in terms of measurement/command/control rates, to support ground test and 
checkout activities. However, another facet of computer capacity that must 
be evaluated is the quantity of main memory space provided versus required. 

The baseline definition used in the study was that the CDMS computer had a 
32,000 16-bit word capacity. 
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Figure 4.1-3. Laser Ranging Experiment 
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Table 4.1-4. Laser Ranging - Checkout Operations 


Steps 

* ' f 

-f 

0 

Activate console; verify Orbiter data 
interface (data, voice, caution/waming) 

1 

Remove lens cap and window shield 

2 

Check switch/control list 

3 

Check recorder tape capacity ! 

4 

Energize recorder electronics 
Verify recorder operation 

5 

Energize steering electronics and steering 
display; verify steering' operation 

6 

Energize TV camera and monitor 

7 

Verify coolant flew rates 1 

8 

Energize laser electronics, power supply 
and display 

9 

Verify laser operation 

10* 

Select targets and acquire data 
a. Enter run identification data 

11 

Shut down in reverse sequence 

12 

Secure laser optics 

13* 

Annotate and stow tape 

=1 

o 

rt 

part of ground operations; on-orbit only. 
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Table 4.1-5. Engineering Measurement List 


MIRROR GIMBAL ANGLE 

DEGREES 


MOUNT AZIMUTH ANGLE 

DEGREES 


MIRROR GIMBAL DRIVE 

ON/OFF 


MIRROR GIMBAL DRIVE 

SIGNAL 


MOUNT AZIMUTH DRIVE 

ON/OFF 


MOUNT AZIMUTH DRIVE 

SIGNAL 


LASER POWER 

ON/OFF 


LASER POWER 

VOLTAGE 


LASER POWER 

CURRENT 


LASER POWER 

TEMPERATURE 


LASER TRANSCEIVER 

ON/OFF 


LASER TRANSCEIVER 

INTENSITY 


LASER TRANSCEIVER 

TEMPERATURE 


LASER RECEIVER 

ON/OFF 


LASER RECEIVER 

SIGNAL 


LASER RECEIVER 

SIGNAL 


LASER ELECT 

ON/OFF 


LASER ELECT 

PULSE RATE 


TIME INTERVAL 

S 1 GNAL 


DEFLECTION 

S 1 GNAL 


IMAGE CONVERTER 

ON/OFF 


IMAGE CONVERTER 

VOLTAGE 


IMAGE CONVERTER 

CURRENT 


IMAGE CONVERTER 

TEMPERATURE 


IMAGE INTENSIFIER 

ON/OFF 


IMAGE INTENSIFIER 

VOLTAGE 


IMAGE INTENSIFIER 

CURRENT 


IMAGE INTENSIFIER 

TEMPERATURE 


RECORDER DRIVE 

ON/OFF 


RECORDER ELECT 

ON/OFF 

30 MEASUREMENTS 

OPERATOR CONTROLS 

ON/OFF 


OPERATOR CONTROLS 

COMMANDS 

30 COMMANDS 
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As the use of the Spacelab DMS in managing and controlling on-board 
operations, including checkout, performance monitoring, and configuration 
control, was not defined at the time of this study, it was assumed that the 
basic approach of the MSS information management system would be applicable. 

A data bus and remote acquisition units (RAU) , similar to the MSS concept, 
have been identified as part of the Spacelab CDMS. In essence, the approach 
is based upon an interactive man-machine relationship. The man interfaces 
with the data management system through a console that has a multi-function 
keyboard and one or more multi-function readout displays. This approach' is 
analogous to what is commercially known as an intelligent 'terminal. In turn, 
the machine (computer) interfaces with the various subsystems via a digital 
data bus, both for measurement data acquisition and command interpretations. 

The computer has three principal functions : (1) performance monitoring 

and caution /warning backup, (2) format and control of telemetered data, and 
(3) command and control. It was assumed in this study that the Spacelab 
adaptation of the data bus-RAU mechanization to accomplish these functions 
would be as follows. 

Performance Monitoring and Caution /Warning Backup . This function would 
be automatic, continuous, and standardized for the support module^ but' 
variable (for each mission) for the experiments. It is usually constrained 
to engineering housekeeping measurements, some of which go out on the Orbiter 
telemetry to ground, and is the primary utilization of the digital data bus. 
Measurements are sorted by function and associated by usage.- , Each block (or 
page) is accessible in real time to the crew via the display and keyboard 
console. 

The total of these measurements will probably not exceed 1000 data points 
for any one mission, although the mix will change as different missions are 
run. One page is limited to about 2000 alphanumeric character spaces, plus 
the formatting instructions. A data point identifies the measurement, its 
present value, the upper and lower limits of that value, and probably can be 
expressed in 30 characters, or fifteen 16-bit words. Thus, about 15,000 
memory words are needed to provide the display function for 1000 data points. 
Table 4.1-6 summarizes the derivation of the required word total. Figure 
4.1-4 illustrates part of a display page. This does not include the instruc- 
tions necessary to selectively call an RAU and sort the response into the 
proper memory slot. It can be assumed that most of this function is pre- 
programmed into the data bus controller, which has its own buffer memory or 
at least uses a direct memory access channel into the computer memory. About 
2000 words should be allotted in the computer operating system to control 
this data flow. 

It can be assumed the display is driven by its own buffer memory, which 
generates the characters and format. The display is self-regenerating (at 
60 frames per second) and updated by the computer once per second. 
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Table 4.1-6. Page Display Characteristics 

ONE DATA POINT PER LINE (30 CHARACTERS, MAXIMUM) 

64-CHARACTER ALPHABET (6 BITS PER CHARACTER) 

TWO CHARACTERS PER 16-BIT COMPUTER WORD 
ONE LINE (30 CHARACTERS) EQUALS 15 WORDS 

DISPLAY FORMAT ABOUT 2000 CHAR-SPACES, 24 LINES OF 80 CHAR EACH 
ONE PAGE DISPLAYS 40. DATA POINTS AND REQUIRES 600 WORDS 
1000 DATA POINTS EQUALS 25 PAGES AND REQUIRES 15,000 WORDS 



Telemetered Data . This function is two-fold: It must (1) select and 

format the digital data to be telemetered and recorded, and (2) select and 
set up the data paths for analog or wideband telemetry and recording. The 
first function covers both the housekeeping data that are interleaved with 
the Orbiter (25.6 kbps) telemetry and the experiment data (256 kbps). The 
housekeeping data are selected similar to the displayed page (except contin- 
uously) and are fed to the Orbiter payload data interleaver. The second 
function also uses the digital data bus. It does not, however, have to be 
converted to the display format. This would require about 1000 words of 
memory space, as a buffer, of which about 100 would be the selection and 
format control overhead. 

Command and Control . The payload specialists are directly involved in 
these functions and utilize the data management system as their communicating 
tool or mechanism. The computer assists the payload specialists by storing, 
retrieving, and formatting pages of set-up procedures, checkout steps, etc., 
and translating keyboard depressions into data bus commands to actuators, 
switches, etc., as illustrated by the page in Figure 4.1-5. The library 
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function is by far the largest consumer of memory space. Recalling that one 
page requires about 600 computer words, then 100 pages (of text) would use up 
60,000 16-bit words. Each page is about 250 English words, about the same as 
a typewritten page. 



Memory Requirements Summary . Summation of the memory requirements 
indicates : 

. Performance monitoring/caution-waming 15,000 words 

. Telemetry 1,000 words 

. Command /control (100 pages) 60,000 words 

A computer main memory of even 64,000 words cannot contain all of this 
at one time. However, only the performance monitoring (PM) and the telemetry 
(TLM) are required in residence at all times; only one, two, or three pages 
of command/control data can be utilized at one time. If the computer memory 
is extended by a tape recorder (mass memory) with a reasonable access time 
(3 to 4 seconds), then a very large number of pages can be retrieved without 
saturating the computer main memory. 

The allocation of the SM computer memory is indicated on Figure 4.1-6. 

A total of 16,000 32-bit words is currently allotted to applications programs 
for SM support system and experiment control and monitoring. The estimated 
requirement for normal operation of the SM is 7.5 K words. An additional 
8.5 K words are available for growth. These data are based upon a generalized 
analysis conducted by MSFC on the Phase B definition of the Spacelab ( Spaeelab 
Sortie Payload Software Sizing Analysis 3 MSFC, February 1974). The three 
baseline ATL payloads used in this study were analyzed to establish their 
memory requirements and, in all three cases, less than 5 K words were required. 
It should be noted that the requirements reflected on this figure are for the 
memory to conduct operations. Sensor data processing/resolution is an addi- 
tional requirement. 
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Checkout Compatibility 

The evaluation of the capability of the CDMS to accommodate operations and 
memory requirements indicated that the preferred approach of using the CDMS 
during checkout was feasible. But, for the CDMS to be used in this manner 
it must be verified as an instrumentation system prior to conducting tests on 
other equipment. An assessment of the impact on the test and operations 
sequence was conducted. Ground rules were established to define the status 
of the CDMS at the initiation of testing. Although the SM is used as the 
example in the ground rules, these rules are equally applicable to an SM sim- 
ulator. For example, the post-test revalidation of a simulator is comparable 
to the post-flight refurbishment of an SM. The ground rules are as follows. 

1. The checkout is not for a first time operation, but an Nth-time 
cycle. The implication of this rule is that a large part of 
the SM module will remain intact; only parts that have reported 
failures are expended or will not be used on the next mission and 
are removed. What remains need not be reverified component- 

by- comp onen t . 

2. The CDMS will be used for Spacelab support system verification. 

The CDMS performs this function for the entire Spacelab during 
the mission, and should be able to perform the same function 
for ground operations. It can readily be conceived as another 
terminal of the launch processing system; of the concept veri- 
fication systems; or any other ground simulation, test, and 
recording system. 

3. The SM support systems, and the CDMS in particular, will not be 
completely disassembled, checked, and then reassembled. This 
ground rule eliminates a common source of malfunction — the 
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accidental breakage of cables, wires and connectors. It also 
eliminates a large amount of time that would be needed to 
reverify the instrumentation system. 

4. Refurbishment and modification shall be on a remove- and-replace 
basis. The actual repair, test and certification of components 
and subassemblies is a bench operation, is considered to be 
off-line, and is not part of the SM test and checkout operations 
flow. 

5. Only those components that have been replaced, or added, are 
checked out at the module level; the remainder are verified by 
normal operation. This ground rule follows No. 1, in that 
most of the SM elements have demonstrated their capability and 
integrity on the previous missions, which is excellent evidence 
that all the parts are working properly, and working together. 

Based upon these ground rules, an estimate was made of the serial time 
that would be required to utilize the CDMS during checkout. Two types of 
activities were assessed: (1) initiation of checkout, and (2) status veri- 

fication. 

Initiation of Checkout . These activities relate to the verification/ 
certification that the SM (or SM simulator) is operational and can support 
the checkout of experiment equipment and/or Orbiter interfaces in the test 
configuration. It is assumed that the basic operational capability of the SM 
(in a etand-alone state) was demonstrated previously. The steps and time 
estimates are as follows. 

STEP 1. COMPUTER SELF-TEST. This is a standard program stored in 
the mass memory, complete with test problems, error checks and 
diagnostics. The computer, keyboard and displays, and tape recorder 
are needed. Estimated time for verification is 10 minutes (assume 
no fault) . 

STEP 2. INSTRUMENTATION SELF-TEST. This is another standard pro- 
gram that exercises the data bus and RAU’s by sequentially inter- 
rogating each one for a status check. The status check is a 
built-in test function in the RAU. Estimated time for verification 
is 2 minutes. 

STEP 3. COMMAND /CONTROL VERIFICATION. The computer is loaded with 
programs that interpret manual keyboard and hand-controller func- 
tions, and any special display format functions. The operator then 
commands, via his controls, selected operations which are simulated, 
and the results displayed for his evaluation. Estimated time for 
verification is 2 to 3 hours. 

STEP 4. PERIPHERAL EQUIPMENT VERIFICATION. These are additional 
programs to exercise data recorders, printers, plotters, etc. 

These are test signals — that is, simulated data that are inserted 
to verify the correct operation. Estimated time for verification 
is 1 hour. 
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STEP S. AUXILIARY EQUIPMENT VERIFICATION. These are manual (not 
computer) actions to verify the CCTV operation, the film equipment, 
etc. , like a check list. Estimated time is 1 hour. 

STEP 6. ORBITER UMBILICAL VERIFICATION. Certain signals (caution/ 
warning, voice, data) will cross the interface via an umbilical; the 
Orbiter would be simulated by GSE. This is primarily a wiring check 
where the operator selects a wiring path, injects a stimulus, and 
observes a response. Estimated time is 2 hours. 

In the worst case, the initialization of a test configuration would be 
less than one work day. 

Status Verification . Only three steps are required prior to commencing 
daily test activities. Two of the three steps are the same as the initiali- 
zation steps. The steps are as follows. 

STEP 1, COMPUTER SELF-TEST. Same as initial verification. 

STEP 2. INSTRUMENTATION SELF-TEST. Same as initial verification. 

STEP 3. EXPERIMENT DISPLAYS AND CONTROLS VERIFICATION. The 

experiment-unique displays and controls are presumed to be hard- 
wired to the rack/pallet-mounted experiment equipments. As the 
experiment equipments are the items undergoing integration/check- 
out, the status will be varying throughout the test sequence. A 
manual status check must be accomplished prior to commencement of 
daily operations. The CDMS can be utilized to provide the refer- 
ence data page for status check. Estimated time for verification 
is dependent upon the equipment undergoing checkout; CDMS time is 
negligible. 

Summary of Checkout Compatibility . Evaluation of the impact of the pre- 
ferred checkout approach on the serial time of tests and operations indicates 
that not only is the approach compatible but will facilitate the checkout 
process. Even if the worst case were assumed, test configuration initializa- 
tion within eight hours is a significant improvement over manual approaches. 
Similarly, daily status determination is accomplished in minimum time. 

Evaluation of SM Simulator Usage 

The definition of the preferred checkout approach included the use of an 
SM simulator during Level III integration. In order to assess the impact of 
including an SM simulator on the checkout sequence, it was necessary to deter- 
mine the effects on total serial processing time of the flight hardware and 
the required complement of flight hardware to support the anticipated Spacelab 
traffic model. 

Checkout Sequence Without Simulator ' 

Processing times based upon the nominal period required for the complete 
Spacelab concept were used in the analysis. A single-shif t/five-day work week 
was assumed. Figure 4.1-7 illustrates the time that each flight hardware 
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element [support module (SM) , racks/pallet (R/P)] would be involved if a sim- 
ulator were not used. The first bar is the five weeks required for experiment 
installation and checkout. During this period, only the R/P is required. The 
shaded bar is 21 weeks long. During this period of time Spacelab integration, 
Orbiter-cargo integration, launch, mission, post- landing, and SM-R/P refurbish- 
ment operations occur. The SM is involved for the entire 21-week period. 

(It should be noted that there are variations of up to 1.5 weeks in this 21- 
week period because of differences in shipment requirements between concepts.) 
The launch is shown to be five weeks prior to the completion of the shaded 
bar. The activities in those five weeks consist of: 

Weeks 

1 Mission 

2 Post-mission operations including Spacelab shipment 

2 SM, rack/pallet refurbishment 


R/P ONLY (NO. 1) 


t/P ONLY I 

m 

(irfe 


LAUNCH 


26 WEEKS 


SM (NO. 1) + R/P 


( 21 ) 


LAUNCH 


V////////////////////////A 


( 21 ) 


R/P (NO. 2) 


| T 

LAUNCH 


3-WK OR BITER TURNAROUND 


(5) 



SMIN0.2) i AIINPH 

(21) 1 

I I 


(5) 1 



( 21 ) 


SM R/P 
1 1 

2 FLTS/YEAR | 


SM R IP 

2 2 

1 -4 FTLS/YEAR \ 


Figure 4.1-7. Checkout Sequences Without Simulator 


The 21-week period was shaded to illustrate that during this period, the 
SM and the rack/pallet are both required in the operations as contrasted to 
the 5-week period of experiment installation during which only the rack/pallet 
assembly is required. Thus, the Spacelab has a 26-week processing cycle that 
results in one SM and one R/P being able to support a flight rate of two 
flights per year. If a flight rate of four flights per year were required, 
then an additional R/P and SM would be needed. If desired, the processing 
cycle of the second Spacelab could be staggered so that the time between 
flights could vary anywhere from 3 to 13 weeks. The lower limit is defined 
by the 3-week turnaround time for the Orbiter. 

Checkout Sequence With Simulator 

Figure 4.1-8 is similar to 4.1-7 with the exception of the introduction of 
a simulator in the checkout sequence. The effect of the simulator Is that it 
reduces the serial processing time of the SM from 21 weeks to 12 weeks. Based 
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on the flows illustrated, one simulator with one SM and two R/P’s can support 
a flight rate of four flights per year. This combination of equipment has 
the following processing cycles: 

Weeks 

2 Simulator 
12 Support module 
26 Racks /pallet 


R/P (NO. 1) ONLY (26 WK CYCLE) S IMUL SM R /P SET 



Figure 4.1-8. Checkout Sequences With Simulator 
Comparison of Approaches 

Based upon the involvement times of the equipment in Figures 4.1-7 and 
4.1-8, the required complement to support various flight rates for the two 
approaches was determined. Figure 4.1-9 summarizes the flight-rate sensitivity 
for the two approaches. For a Spacelab program that envisions a flight rate 
of one or two flights per year, the choice of using a simulator during check- 
out is concept- dependent. While the use of the SM in this situation has the 
obvious plus of saving the delta cost of an SM simulator, the utilization of 
the SM is not maximum. In Concept I, the IC was the owner of the SM and was 
defined as a centralized activity for the support of multiple Spacelab users. 
Maximum utilization of the SM is required. Similarly, in Concepts II, III, 
and IV the launch site is the SM owner and also would support multiple users 
with maximum utilization of the SM. In Concept V, the user owns the SM and 
if only two flights per year are planned, the use of a simulator is question- 
able. One SM would support the operation; there is no apparent justification 
for the delta capital investment for an SM simulator. 


4-23 


SD 74-SA-0156 



Space Division 
Rockwell International 


•WITH SIMULATOR 



SIMUL 

SM 

EM/P 

PROCESSING 
CYCLE (WEEKS) 

■ 

12 

26 

MAX CYCLES 
PER YEAR 
(ONE ITEM) 

■ 

D 




•SM ONLY 



SM 

EM/P 

PROCESSING CYCLE 
(WEEKS) 

21 

26 

MAX CYCLES PER YEAR 
(ONE ITEM) 

n 

■ 




ELEMENTS REQUIRED | 

ANNUAL 

PLIGHT 

WITHOUT 

SIMULATOR 

WITH | 

SIMULATOR | 

RATE 

ESI 

MJaM 

ESI 

jg| 

m 


i 

i 

1 

1 

1 

1 

i 

i 

i 

i 


2 

2 

1 

i 

2 


2 

2 

1 

i 

2 

5 

3 

3 

1 

2 

3 

6 

3 

3 

1 

2 

3 

7 

3 

4 

2 

2 

4 

8 

4 

4 

2 

2 

4 

9 

4 

5 

2 

3 

5 

10 

5 

5 

2 

3 

5 

II 

5 

6 

2 

3 

6 

12 

6 

6 

2 

3 

6 

13 

6 

7 

3 

3 

7 

14 

6 

7 

3 

4 

7 

IS 

8 

8 

3 

4 

8 


Figure 4.1-9. Spacelab Modules and Simulator Complement 

Vs . Flight Rate 

At flight rates greater than two per year, there are cases when the 
simulator approach requires one additional item of equipment (flight rates 
of 7, 9, 14). But the additional item is always a simulator. In these 
cases, the non-simulator approach would be preferred if the simulator costs 
were greater than one-half the cost of an SM. But, with proper design and 
selection of equipment, it is believed that an SM simulator should cost less 
than one-fourth the cost of an SM. In addition, the simulator approach avoids 
the schedule risk of near-continuous use of the SM and maximizes the utiliza- 
tion of the single most costly item in the Spacelab program, the SM. Even 
in Concept V, the use of a simulator is recommended at flight rates of two 
or less per year. With the simulator, a user that owns an SM can share the 
use, and thus the costs, of an SM. 
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CHECKOUT REQUIREMENTS 

Three categories of checkout requirements were evaluated: functional, 

environmental, and operational. The preferred checkout approach emphasized 
the demonstration/verification of planned flight operations. The functional 
checkout requirements must reflect not only this approach, but also the 
buildup of the assembly levels and the potential interactions between the 
payload and the Spacelab/Orbiter . Environmental test requirements should 
reflect the potential interactions of an integrated payload. It was assumed 
that the individual experiment equipments, Spacelab, and Orbiter would be 
certified to operate in the anticipated environments. Hardware processing 
techniques (operations) could impose unique test and/or installation require- 
ments and directly impact the sequence of activities. The ground operations 
should reflect a logical buildup sequence and minimization of repeat testing. 

Functional Checkout Requirements 

As the Spacelab/Orbiter were considered to be operational and the 
integrated payload was mission-unique, two different sets of functional test 
requirements were identified. 

Spacelab/Orbiter 

During the operational era of the Spacelab/Orbiter the capabilities, 
limits, and constraints of these two program elements will have been well- 
established. Systems performance characteristics, maintenance schedules, 
trend data, and refurbishment schedules will have been derived based upon 
developmental and operational flights. Also, crew safety provisions and pro- 
cedures will have been verified. The goal is to reach an operational status 
comparable to a commercial airline. 

One additional characteristic of the Spacelab/Orbiter concept is the 
establishment of a line-replaceable-unit level that precludes detailed on-line 
testing of subsystems. That is, only interfaces between major subassemblies 
need to be verified. If a subassembly malfunctions, the entire unit is 
replaced; on-line troubleshooting within a subassembly is not planned. 

These planned characteristics of the Spacelab/Orbiter program elements 
preclude the detailed testing at each level of assembly that was required on 
past space programs. Because the Spacelab/Orbiter are reused many times, only 
a revalidation of the functional operations is required. A complete teardown/ 
buildup of equipments is not required. End-to-end tests of subsystems are 
adequate unless a subassembly has been replaced based upon mission operation, 
trend data, or maintenance schedules. The test sequences presented subsequently 
in this volume reflect only the functional reverification of Spacelab/Orbiter 
systems with allowances for periodic maintenance of equipments. 

In general, Spacelab/Orbiter interfaces also are repetitive from flight 
to flight. The performance characteristics of the interfaces will have been 
established. Therefore, during Level II integration, Spacelab/Orbiter inter- 
face compatibility demonstrations will be minimal. During Level I integration, 
interface verification tests are primarily to verify workmanship/integrity 
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of interconnections. The subsequently developed test sequences reflect the 
standardization and repetition of Spacelab/Orbiter interfaces. (Orbiter/pay- 
load interfaces are mission-unique and will require detailed compatibility 
evaluations . ) 

Experiment Systems 

In order to establish the integration and checkout requirements associated 
with experiment systems, the pre-integration status of the experiment equipments 
must be defined. Throughout the development of the integration and checkout 
process, emphasis has been placed upon the retention of experiment equipment 
ownership /cognizance by the Pi’s. This ownership/cognizance includes establish- 
ment and verification of the performance capability and constraints of the 
individual experiment equipments. This verification must be accomplished prior 
to introduction of the equipments into the payload integration process. Opera- 
tional interface verification or functional operation in the installed configur- 
ation is the primary test task of the integration and checkout process. 

The Spacelab/Shuttle offer a unique space platform-launch vehicle. In 
previous space programs, almost the entire spacecraft-launch vehicle was crew- 
safety related. During the Spacelab/Shuttle operational era, crew safety 
provisions will be provided by these two elements. The experiment systems/ 
payload must be designed for safe operations but need not include specific crew 
safety equipment. 

The close-couple between safety and reliability of previous space programs 
can become two separate functions with Spacelab payloads. Repetitive testing 
of payload equipment to establish a high degree of confidence/assurance of the 
adequacy of crew safety provisions is not required. Because experiment equip- 
ments are not part of the crew safety provisions, multiple equipment paths and 
high degrees of redundancy are not required. Reliability and quality assurance 
of experiment equipments is the responsibility of the Pi's — not the payload 
integrator or Spacelab/Shuttle operator. Repetitive testing at the various 
assembly levels will not be required. 

Safety will still be a stringent requirement for all payload equipment. 
Provisions must be included for the protection of personnel and equipment dur- 
ing all phases of both ground and flight operations. In some cases, these 
provisions must be demonstrated during checkout. For example, payload sensors 
that must be extended beyond the Orbiter mold line must include jettison pro- 
visions as well as normal retraction capability. 

To ensure the safety of operations, a group of qualified personnel should 
be planned to conduct payload safety evaluations. The group would work directly 
with the Pi's as well as the payload integrators. The specific tasks that this 
group would perform are as follows : 

1. Prepare guidelines and criteria for safety, possibly assembled from 
existing safety manuals and provided to cover hazardous materials 
and procedures. These guidelines and criteria would be used by the 
Pi's to understand and avoid potential hazards and to preclude the 
requirement for safety demonstration tests. 
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2. Conduct hazard analyses, in conjunction with the Pi's, of proposed 
and existing experiment equipment designs, test procedures, and 
operational procedures. A systematic analytical study of each 
experiment system could eliminate potential hazards and simplify 
the test activities. 

3. Develop a review/approval , go/no-go procedure for all materials, 
designs, and procedures. This approach will establish confidence 
in the safety of experiment systems and minimize demonstration 
test requirements. 

All of the safety group tasks have two objectives: safe operations, and 

minimization of testing. The test and operations sequences developed subse- 
quently in this volume reflect the use of a safety group in minimizing/def ini- 
tizing safety- related tests during Spacelab-payload and Orbiter-cargo hardware 
integration. 

The assumed status of experiment systems at the initiation of payload 
integration negates testing and retesting of experiment equipments as the levels 
of assembly progress. Testing of equipment after each hardware transfer/major 
move to s ain assurance that equipment validity was maintained is not necessary 
in a continuing program. Standardized/controlled moves with predictable envir- 
onments would be established. The short mission times, known flight environ- 
ments, and familiarity with the constraints of near-earth space operations, 
coupled with the disassociation of experiment equipments and crew safety pro- 
visions, permit a de-emphasis on multi-level testing. 

Composite Requirements 

Figure 4.1-10 summarizes the functional checkout requirements for an 
Orbiter/Spacelab/payload. Functional operation in all operating environments 
of the Spacelab, Orbiter, and individual experiment systems has been verified 
prior to initiation of integration and checkout activities. Only functional 
reverification and operational interface verification is required of the 
Spacelab/Orbiter. 1 Functional checkout of experiment systems in the installed/ 
integrated configuration is required as well as functional verification of 
interfaces between experiment systems and Spacelab/Orbiter systems. 

Every retest expends programmatic resources. Also, schedules become more 
critical as the level of assembly increases. In particular, as the level of 
integration approaches the launch configuration there is insufficient time to 
repeat previously verified operations. Therefore, the functional test philos- 
ophy adopted m this study was that once an integrated operation in the flight 
configuration (at any level of assembly) has been verified, that verification 
will not be repeated. Only interfaces will be verified at subsequent assembly 
levels. For example, the only operations that must be verified after Spacelab 
integration (Level II) are the interfaces that result from the interconnection 
of the Orbiter with the Spacelab/payload. Spacelab interfaces with the payload 
would not be reverified during Level I integration. The checkout sequences 
presented subsequently in this volume reflect this functional checkout 
philosophy. 
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FUNCTIONAL CHECKOUT 
REVERI FI CATION 

OPERATIONAL INTERFACE 
VERIFICATION 


OPERATIONAL INTERFACE 
VERIFICATION 


INTEGRATED FUNCTIONAL CHECKOUT 
FUNCTIONAL INTERFACE VERIFICATION 


• SPACELAB EXPERIMENTS 

• SPACELAB/ORBITER 


Figure 4.1-10. Program Potential Test Matrix 


Environmental Checkout Requirements 


The various environments that experiment systems will be exposed to dur- 
ing hardware processing are as follows : 

* Acceleration * Vacuum 

* Shock ’ Thermal 

* Vibration (structurally induced) * RFI/EMI 

* Acoustic vibration * Humidity, dust, and corrosive 

atmosphere 

Table 4.1-7 indicates the ground and/or flight operations that will impose 
the various environments and which operations will impose the maximum envir- 
onmental stress. From past space programs, experience has shown that accept- 
able methods of verification of equipment compatibility with anticipated 
environments are: (1) similarity (with hardware previously flown or tested), 

(2) analysis, (3) simulation tests (tests of simulated hardware), and (4) test 
of mission hardware. The environmental compatibility verification/certifica- 
tion activities of several previous space programs were evaluated to determine 
an applicable and preferred approach for Spacelab payloads. 
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Table 4. 1-7 Experiment Environments 


Operation 

Thermal 

Vacuum 

Shock 

Acceleration 

Vibration 

Acoustic 

Humidity, 
Dust, Cor- 
rosion Atmos 

EMI 

RFI 

Experiment Development/ 
Acceptance 

Ambient 

— 

Handl mg 

— 



— 

— 

Indoor 

GSE test 
equipment 

— 

Ship to integration facility ^ 

— 

— 

Transport* 

— 

Transport 

— 

Outdoor* 

— 

— 

Experiment integration 
(Level III) 

-- 

— 

Handl mg 

— 

— 

— 

Indoor 

Other expmt 
GSE* 

Other 

experiments 


— 

— 

Transport 

— 

Transport 

— 

Outdoor* 

— 

— 

Spacelab integration 

— 

— 

Handl ing 

— 

— 

— 

Indoor 

Spacelab, 
expmt, GSE* 

— 

T ransport 

— 

— 

Transport 

— 

Transport 

— 

Outdoor* 

— 

— 

Orbiter/Cargo Integration 
(Level 1) 

— 

— 

1 

1 

— 

— 

— 

Indoor 

Orbiter, 
Spacelab, 
Experiment * 

— 

Prelaunch operations 

— 

— 

Move to 
pad 

— 

Move to 
pad 

— 

Shuttle 

payload bay 

— 

— 

Launch and boost to orbit 

Orbiter 
payload bay 

Sea level to 
space vac 

Booster 

engines 

Boost 

X-axis* 

Rocket engine 
and aero 
vibration* 

Rocket 
engine and 
aero loads * 

Orbiter 
payload bay 

— 

— 

Orbital operations 

Solar and 
deep space* 

Space 
vacuum * 

-- 

— 

— 

— 

— 

Orbiter, 

Spacelab, 

Experiment* 

Orbiter, 
other expmts 

Deorbit and entry 

Orbiter 
payload bay 

Space vac . 
to sea level 

OMS 

engines 

Deorbit 
X-Y axes 

OMS engine 
& aero vib 

Aero loads 

Orbiter 
payload bay 

— 

— 

Landing 

— 

— 

Landing * 

Braking 

— 

— 

Orbiter 
payload bay 

— 

— 

T ransport 

(to Level III integration site) 

— 

— 

T ransport 

— 

Transport 

— 

Orbiter 

— 

— 

‘Maximum stress. 
^Individual experiments — cc 

mmercial carrier 
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Previous Space Programs 

The following paragraphs discuss several orbital and airborne experiment 
programs that were evaluated to provide insight into practices employed for 
verifying payload compatibility with the carrier vehicle and mission environ- 
ments before commitment to the mission. Both manned and unmanned space programs 
were considered. 

Apollo "J" Missions . These missions comprised three lunar landing 
flights: Apollo 15, Apollo 16, and Apollo 17. On these missions, a number 

of scientific experiment payloads were installed in the Scientific Instrument 
Module (SIM) bay (Sector IV) of the Service Module. This sector was cleared 
of Command and Service Module (CSM) subsystem hardware and was enclosed by a 
door which served as structure during launch and boost, and which was jetti- 
soned by pyros just prior to lunar orbit injection to expose the experiments 
to space. 

Experiment hardware was qualified for the J-missions by functional and 
environmental testing to specified levels during development. Apollo electro- 
magnetic compatibility (EMC) requirements were included. The actual flight 
hardware underwent acceptance testing to predicted flight environment levels. 

The Service Module SIM bay was qualified by vibration testing of Apollo 
Spacecraft 105 (SC105) , with simulated experiment masses, in the acoustic 
vibration chamber at JSC. Thermal- vacuum qualification tests were performed 
on the thermal-vacuum test article, SC-2TV2 (with SIM bay), and experiment 
test hardware in Environmental Chamber A at JSC. 

Verification of experiment hardware flight readiness for the three J- 
missions was based on acceptance tests (to flight levels) and by similarity 
to qualification test hardware. 

Functional compatibility of experiment hardware, including EMC, was veri- 
fied by checkout tests after installation in the SIM bay. Experiments were 
installed while at the MSOB, except for some late experiments which were 
installed at the launch pad. This delayed complete functional experiment ver- 
ification to checkout at the launch pad (with some increased risk to the exper- 
iment program) and precluded environmental testing of the integrated flight 
payload. 

In summary, J-mission experiment hardware underwent qualification testing 
during development. Functional compatibility with the vehicle was verified by 
checkout testing after installation, and environmental compatibility was veri- 
fied for the first mission by the acoustic vibration chamber test and the 
thermal- vacuum chamber test described above. Environmental compatibility for 
the second and third missions was based on similarity with the first mission. 

Skylab Program . This program included experiment and module configura- 
tions with significant analogies to the Shuttle/Spacelab program. The booster 
used was the two-stage Saturn launch vehicle, consisting of the S-IC and S-II 
stages. The Skylab configuration consisted of five major elements, four of 
which were enclosed in a payload shroud during boost. The major elements were 
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a multiple docking adapter (MDA) , which provided the' docking interface with 
the CSM and supported the majority of the earth resources experiments; an 
airlock module (AM) , which provided an airlock to space and controls for 
operational systems; an Apollo telescope mount (ATM), containing a large 
telescope and six solar experiment sensors; an orbital workshop (OWS) , con- 
taining crew quarters and experiment facilities; a Saturn V instrument unit 
(IU) , used only during launch and initial deployment; and a payload shroud 
(PS), used during boost to orbit. The ATM provides a good analog with pallet- 
mounted experiments, while experiments in the OWS, MDA, and CSM contained 
experiments analogous to those in the Spacelab experiment module. 

The various Sky lab modules were environmentally verified by analysis, 
test, and similarity. Environmental tests were not conducted on the complete 
Sky lab configuration, which was verified by analysis. 

The OWS (an S-IVB structure) underwent vibration testing in the acoustic- 
vibration test facility at JSC. The vibration test article consisted of the 
OWS structure and furnishings with mass simulated subsystems and experiments. 
Thermal-vacuum testing was performed on the refrigeration and waste management 
subsystems in the environmental' chamber at McDonne 11- Douglas , Huntington Beach, 
California, and on a single, panel of the solar arrays in a TRW environmental 
chamber. Experiments in the OWS underwent environmental qualification and 
acceptance tests during development. 

The AM' and MDA modules were assembled and underwent manned thermal-vacuum 
chamber tests at McDonnell-Douglas, St. Louis, Missouri. Acoustic-vibration 
tests were performed with a vibration test article similar to the flight 
article. 

The ATM was assembled together with the telescopes and sensors, and 
vibration- tested as a complete package in the MSFC vibration test facility. 

It was then shipped to JSC for a 28-day therma-vacuum test in a JSC envir- 
onmental chamber. While vibration and acceleration loads measured during 
boost were in agreement with analytically predicted values (frequency within 
10 percent, and steady-state and dynamic accelerations within 1.5 percent), 
a telescope pointing problem occurred during orbital operations. Instability 
in the telescope pointing control system was associated with structural vibra- 
tion modes induced by crew exercise activity and attendant vehicle attitude 
control maneuvers. Vigorous crew activity during exercise exceeded that 
defined in the crew activity model, and induced vibrations at the ATM beyond 
the rate capability of the attitude pointing control system. The operational 
fix consisted of limiting crew activity and vehicle maneuvers when taking 
data. 


The payload shroud underwent pyrotechnic separation tests in a vacuum 
chamber at Langley. It was verified for the acoustic-vibration environment 
by similarity with a shroud used on a comparable USAF program. 

The Sky lab carried 60 items of experiment hardware in the various modules, 
as shown in the following tabulation. 
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MODULE 


NO. OF EXPERIMENT 
HARDWARE ITEMS 


ORBITAL WORKSHOP (OWS) 45 
MULTIPLE DOCKING ADAPTER (MDA) 4 
APOLLO TELESCOPE MOUNT (ATM) 9 
COMMAND & SERVICE MODULE (CSM) 2 


TOTAL 60 


Experiment hardware was required to demonstrate functional and environ- 
mental capability by qualification and acceptance tests performed by the 
responsible experimenters. Most of the flight hardware was located in the 
OWS. Experiment hardware (not necessarily the final flight hardware) was 
installed, and functional tests were performed at McDonnell- Douglas, Hunting- 
ton Beach, California. This hardware was removed for shipment of the OWS to 
KSC. Some equipment was modified or replaced before shipment to KSC, where 
it was all re-installed in the OWS and functional integrated checkout testing 
was performed on the complete Skylab in the protected environment of the VAB. 
Only limited testing and servicing was accomplished at the launch pad. 

Electromagnetic compatibility requirements were imposed on all experi- 
ments and Skylab subsystems, and verified by qualification test and acceptance 
tests. Electromagnetic compatibility was monitored at each stage of integra- 
tion and checkout prior to launch. 

P72-2 Spacecraft . This spacecraft program carries and provides functional 
support for four .experimental payloads. It is launched on an Atlas rocket 
booster and placed in circular orbit by a solid propellant rocket motor (apogee 
insertion motor). 

During the development phase of the program, a modal vibration test was 
performed on the spacecraft structure with mass simulated subsystem hardware 
and experiments to verify and modify the dynamic analysis model. This test 
provided sinusoidal excitation at selected input points to determine natural 
frequencies, general response profile, and damping characteristics. The modal 
test was supplemented by testing in an acoustic chamber at Rockwell Los Angeles 
Division, where the suspended spacecraft and simulated payloads were subjected 
to acoustic environment at 6 dB below and at full predicted flight environ- 
ments. These tests were conducted early enough to permit structural design 
changes (e.g., bulkhead stiffeners). 

As a part of the Phase III integrated test, the final P72-2 spacecraft, 
complete with subsystem hardware and payloads (except for a simulated apogee 
insertion motor), underwent acceptance testing in a TRW acoustic chamber at 
3 dB below and at full predicted flight levels. Measured vibration levels on 
components were within the levels predicted. 

A performance test of thermal insulating techniques used to minimize para- 
sitic heat transfer to the RM-20B* payload radiator was conducted during the 

*Experiment designation used on the P72-2 Spacecraft program. 
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development phase. The test was conducted on a radiator with structural 
interface and heat shield in a Space Division environmental chamber with 
-320 F (LN2) c °ld walls and 10”^ torr vacuum. 

Later, during the integrated systems test, the complete P72-2 Spacecraft 
with actual subsystem hardware and payloads (except apogee insertion motor and 
squibs) underwent thermal-vacuum testing in an environmental chamber at 
McDonnell-Douglas , Huntington Beach, California, to demonstrate the spacecraft 
capability to maintain the temperature-critical components and interfaces 
within specified limits during all critical mission phases. Measured temper- 
atures were within analytically predicted limits. 

EMI requirements for susceptibility and emission were specified for sub- 
systems and experiments. The EMI characteristics of individual equipments 
was established during acceptance testing. EMI was emperically evaluated at 
each level of integration. Both hardware and specification changes /waivers 
were required. 

CV- 990 Airborne Research Program . The NASA-Ames Airborne Science Office 
(ASO) has conducted a program of airborne flight tests for selected experi- 
ments since 1965, using a Convair 990 jet aircraft (CV-990) as the carrier. 
Flights are scheduled locally and worldwide for conducting astronomical and 
earth-viewing experiments at flight altitudes to 15 km. Single astronomy 
experiment payloads have also been flown in Learjet and Lockheed C-141 
aircraft. 

A major objective of this program is to reduce cost and enhance research 
accomplishment by full experimenter involvement and responsibility. This is 
achieved by placing full responsibility for the performance and reliability 
of the experiment upon the experimenter,. ASO requires only that the experi- 
ments satisfy flight safety requirements. This involves a design safety 
review of drawings, photographs or sketches, plus stress calculations of the 
experiment installation. The hardware installation is inspected by aircraft 
inspectors. Any experiment testing is at the discretion of the experimenter, 
and documentation of test results is not required by ASO. 

ASO provides an experimenter's handbook outlining capabilities of the 
CV-990 and the experiment support available, including power and data record- 
ing capabilities. Experiment construction requirements and safety standards 
are also included. 

It should be noted, however, that all experiments actually undergo flight 
environmental testing in the mission preparation process. After experiment >. 
installation in the aircraft, a pilot check flight is conducted with only ASO 
personnel on board. Following this flight, one or more initial operational 
shakedown flights are made with the experimenters aboard. The data producing 
mission flights are then conducted. 

Experiment compatibility with the aircraft electrical and avionics systems, 
as well as interfaces and interference with other experiments, is checked dur- 
ing pre-flight checkout and on the operational shakedown flights. Final veri- 
fication with the automated digital data acquisition system (ADDAS) is conducted 
on the shakedown flight. 
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The ASO program flights from 8 April to November 1972 were reviewed to 
assess applicability of the approach to Shuttle-Spacelab operations. This 
review included five CV-990 missions involving 62 experiments and 76 exper- 
imenters, plus 17 Learjet missions with 17 experiments and 50 experimenters. 

The CV-990 missions typically carried 5 to 15 experiments for up to 10 flights, 
over a period of 4 to 6 weeks. Learjet missions carried one astronomy exper- 
iment per mission for 4 flights over a period of 1 to 2 weeks. Of the 
experiments conducted during this period, only 5 percent resulted in complete 
data loss due to malfunctions, while 68 percent experienced no malfunctions. 
Twelve percent had malfunctions which were repaired in flight with no data 
loss, and 15 percent had malfunctions with some data loss. Thus, 80 percent 
of the experiments had no data loss at all, 15 percent had partial data loss, 
and only 5 percent experienced total data loss. 

Advanced Applications Flight Experiments (AAFE) . AAFE is a Langley 
Research Center program that utilizes a C-54 aircraft for airborne research. 

The experimenter is required to submit a plan for reliability and quality 
control, including formal acceptance testing for review. Experiment func- 
tional and environmental test data are submitted to Langley for flight 
acceptance. For example, in the microwave radiometer experiment, the envir- 
onments tested include vibration, shock temperature, and altitude. These 
tests were conducted at Space Division laboratories in Downey, California. 

This program is similar to the Ames CV-990 program in that the airplane 
is operated by Langley with the experimenter being responsible for experiment 
operation. Several experiments can be accommodated on a single flight, neces- 
sitating experiment integration by Langley. Functional compatibility is 
verified by pre-flight checkout tests. 

Scout Program . This program involved launching a single experiment pay- 
load on a Soout rocket. Functional and environmental qualification and 
acceptance tests were required for flight acceptance. The payloads were 
tested for all applicable environments, including spin up. The flight hardware, 
in final form, was acceptance- tested to mission-predicted environments. Func- 
tional compatibility was verified by checkout tests during integration and 
before launch. 

Summary of Previous Program Trends . It is apparent from a review of 
single-mission programs (e.g., P72-2, Scount, Sky lab ) , that confidence in 
payload capability is directly related to an accurate definition of the oper- 
ating environments. Uncertainty in the definition of the environment requires 
the inclusion of margins in the design definition. In addition, first-time 
payload equipment requires extensive testing to develop the confidence 
required to commit this equipment to flight. 

In multiple-mission programs, these uncertainties also apply to first 
flights. However as the program progresses, experience in previous flights 
permits accurate redefinition of the environments, and experience with payload 
hardware provides verification (and modification) of math models to establish 
higher confidence levels. 
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This trend (see Figure 4.1-11) is apparent in the repetition of the 
Apollo J-missions, where initial full-scale environmental testing of the SIM 
bay with simulated or actual experiments preceded the first flight, and where 
the second and third missions were verified for flight by analysis and simi- 
larity. In the Skylab program, emphasis on full-scale testing was maintained 
for new equipment (experiments and subsystems) while capability of the OWS 
(S-IV) and Apollo CM were accepted by similarity. 
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Figure 4.1-11. Trend in Environmental Test Requirements 

The informality of full-scale payload testing in the CV-990 and AAFE 
programs is especially marked. Here, the flight vehicle characteristics and 
environments imposed on experiments were accurately known, and NASA experi- 
ence with flying a variety of payloads made verification by analysis or 
similarity acceptable. 

A major exception to the deletion of tests for multiple-mission programs 
was EMI testing. While susceptibility and output interference limits were 
specified for experiment equipment, potential interaction with other experi- 
ments or with the carrier vehicle cannot be predicted with confidence. Under 
pressure of schedules, EMI requirements are sometimes compromised or waived, 
and interaction with new equipment as payload integration progresses is not 
always predictable. While specific measurements of EMI may be performed on 
individual equipment items, EMC is normally verified by functional testing 
designed to surface EMI effects at each stage of integration. 
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ATL Spacelab Program Environmental Verification Techniques 

Environmental testing of the complete Spacelab and the pallet-only con- 
figurations will be required for qualification/acceptance testing of the 
initial Spacelab flights, and may be required for subsequent Spacelab /exper- 
iment configurations that are very unique. It is reasonable to assume that 
in an on-going program such as the ATL/Spacelab/Orbiter , the carriers would 
have been qualified because of the existence of adequate available facilities 
(not including any European capability). Available environmental chambers, 
capable of the thermal- vacuum testing of the full-scale complete Spacelab and 
pallet-only configurations, are listed in Table 4.1-8. The table lists four 
major thermal-vacuum test chambers, including a description of their present 
capabilities. The payload test requirements are listed in the lower portion 
of the table. It should be noted that in all cases, each facility has suf- 
ficient capability to satisfy the payload requirements. Similarly, the 
acoustic- vibration test facilities, capable of testing the complete Spacelab 
and pallet-only configurations, are listed in Table 4.1-9. 

Since the payload carriers (Spacelab /Orbiter) would have been qualified 
and each individual experiment would have completed a separate environmental 
verification test program, the analysis of the integrated pay load- carrier 
interactions is the remaining issue. The following two subsections establish 
the basic assumptions concerning the Spacelab and experiment hardware elements 
preceding integration, and the environments that the hardware will encounter. 
The final subsection describes the selected environmental verification 
approach. 

Assumptions . The basic assumptions on the environmental verification 
status of the Shuttle, Spacelab, and individual experiments are as follows. 

1. Shuttle and Spacelab modules have been qualified by analysis, 
test, and flight to specified performance and environments. 

2. Spacelab-Shuttle functional compatibility has been demonstrated 
by ground tests and previous flights. 

3. Spacelab compatibility with mission environments has been 
demonstrated on previous flights. 

4. Experiment hardware has been designed and tested to meet 
Shuttle/Spacelab program requirements for functional inter- 
faces and mission environments. 

While these two programs do not specifically require formal 
qualification tests for payload hardware, it is strongly 
recommended that experiment hardware be tested during its 
development to demonstrate compatibility with significant 
mission environments, as defined by the two programs, for 
the following reasons: 

a. Any incompatibility of the experiment hardware with the 
mission environment can be discovered in time to make 
corrections prior to entering the Spacelab ground 
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Table 4.1-8. Thermal Vacuum Test Chambers 


ORGANIZATION 
LOCATION 
FACILITY NAME 


ENV I RONMENTS 
SIMULATED 


CHAMBER 

DIMENSIONS 

(FT) 


MINIMUM 

TEMPERATURE 

(°C) 


PRESENT CAPABILITIES 


SPACE SIMULA. 


MINIMUM WORK 
PRESSURE 
(TORR) 


AEDC 

ARNOLD AF STA (TENN) 
AEROSPACE ENV CHAMBER 
(MK 1) 

SPACE SIMULA. 
SOLAR SIMULA. 
(0-143 W/FT 2 ) 

42D x 82 H 
(34D x 65. 5H, 
WORK SPACE; 
20D DOOR) 

LN 2 WALLS 

5 x 10-9 

NASA-JSC 
HOUSTON, TEXAS 
SPACE ENV SIM. LAL 

SPACE SIMULA. 
SOLAR SIMULA. 
(6 FT D 
130 W/FT 2 ) 

65D x 65 H 
(40 D, DOOR) 

-185 

1 x 10" 6 

BOEING COMPANY 
SEATTLE, WASH (KENT) 
SPACE ENV. LAB 

SPACE SIMULA. 
SOLAR SIMULA. 
(20 FT D; 

130 W/FT 2 ) 

39 D x 50 H 
(28 D x 40 H, 
WORK SPACE) 

ln 2 shrouds 

(H PANEL, 
-253) 

1 x 10"7 
(ULT. 1 x 10-9) 

GENERAL ELECTRIC CO. 
PHILADELPHIA, PA. 

(VALLEY FORGE) 
SOLAR THERMAL VACUUM 
CHAMBER 

SPACE SIMULA. 
SOLAR SIMULA. 
(14 FT D; 

140 W/FT2) 

32 D x 54 H 
(21 D, SPECI- 
MEN) 

-179 

1 x 10-9 


PAYLOAD TEST REQUIREMENTS 

15 D x 60 (MAX) -100 

DEEP SPACE 
DIRECT SOLAR 


1 x 10-6 
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Table 4. 1-9. Acoustic-Vibration Facilities 


ORGANIZATION 
LOCATION 
FACILITY NAME 


AFF DL 

WRIGHT-PATTERSON AFB, OHIO 
SONIC FATIGUE FACILITY 


NASA- JSC 
HOUSTON, TEXAS 
SPACECRAFT ACOUSTIC LAB 


LTV 

DALLAS, TEXAS 
ACOUSTIC LAB 


LOCKHEED MISSILE 6 SPACE 
SUNNYVALE, CALIFORNIA 
LARGE VEHICLE ACOUSTIC 
TEST FACILITY 

WYLE LABS 

HUNTSVILLE, ALABAMA 
ACOUSTIC TEST FACILITIES 


FACILITY TYPE 

CHAMBER VOLUME 
(FT3) S INSIDE 
DIAMETER (FT) 

MAX SOUND 
PRESS. LEVEL 
(dB) 

FREQUENCY 

RANGE 

(Hz) 

ACOUSTIC 

POWER 

(WATTS) 

GENERATOR TYPE 

PRESENT CAPABILITIES 

PROGRESSIVE WAVE 
OR REVERBERANT 

15*1,000 

70 x 56 x 1(2 H 

1 74 (PROG. 
WAVE) 

162 (REVERB) 

50 - 10K 

1000K 
1000 Hz 

PURE-TONE SIRENS 

PROGRESSIVE WAVE 
PROGRESSIVE WAVE 
REVERBERANT OR 
FULL REVERB. 

J*Al ,000 

60 x 70 x 105H 

169 (PROG. 
WAVE) 

153 (reverb) 

20 - 20K 

100K 

AIR MODULATORS 

REVERBERANT 

70,000 
(915 x 15 
ACCESS) 

li»8 

50 - 10K 

20K 

ELECTRO-PNEUMATIC 
(BREADBOARD OR SINE) 

REVERBERANT 

189,000 

M x 50 x 86 H 

156 

40 - 10K 

2A0K 

I 

LING EPT 200 AIR 
MODULATORS, 

WYLE WAS-3000 TRANS- 
DUCERS 

REVERBERANT 

100,000 

60 x 50 x 60 H 

155 

FULL PWR 
25 - 600 
TO 10K @ 
REDUCED 
POWER 

120K 



AIR MODULATORS 
WYLE WAS-3000 


PAYLOAD TEST REQUIREMENTS 


PAYLOAD 
15 D x 60 H 
MAX I MUM 
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processing cycle. Delays will affect only the experiments 
concerned, and would not penalize other experiments or the 
timely progress of the Spacelab integration process. 

b. Experiment characteristics, when exposed to mission envir- 
onments (e.g., vibration), will be useful in analysis of 
the characteristics of the integrated Spacelab and experi- 
ments. Data from experiment environmental tests can be 
combined with data from Spacelab module tests and previous 
Shuttle flights to provide a firm base for verifying compat- 
ibility of the complete payload by analysis and similarity 
with previously flown missions. 

c. Individual experiments can be tested in smaller, more 
accessible, and less costly facilities than the complete 
Spacelab payload. 

ATL/Spacelab Environments . The following paragraphs describe the envir- 
onments to which the integrated Spacelab will be subjected. Also included 
are the primary areas of concern during the major test/processing cycle when 
these environmental effects are encountered, and the method proposed to assure 
that the integrated experiment complement is compatible with the anticipated 
environmental level. 

Shock and Acceleration. The shock and acceleration loads that the exper- 
iment equipment will encounter during ground handling through launch and 
on-orbit operations are nominal. Proper shock mounting can be provided to 
safeguard the equipment during these operational phases. However, a struct- 
ural integrity stress analysis will be required to verify that the experi- 
ments can withstand the crash loads, which are significant. It is understood 
that the experiments will not be expected to operate following their being 
subjected to crash loads, but they will be required to maintain their struct- 
ural integrity and present no hazards. It must be established that the 
experiment equipment undergoing a crash will have the proper structural 
provisions to prevent breakup of the equipment, and thereby eliminate the 
possibility that the experiment equipment could jeopardize crew safety or 
the integrity of the Orbiter. 

Vibration-Acoustic. Vibration analysis will be required for each 
Spacelab payload because mass distribution will vary from mission to mission. 
This is especially true for the pallet-mounted payloads. It is assumed that 
modal vibration and acoustic tests will be conducted during Spacelab develop- 
ment with a variety of payload configurations. This will serve to verify/ 
modify the math model and further refinements will be made after the first 
flights, leading to a high-confidence math model for operational Spacelab 
missions . 

Should a pallet-experiment configuration develop that is not adequately 
covered by the math model, it is proposed that a pallet with experiment- 
simulated masses be tested in an acoustic test facility to verify the natural 
frequencies and damping characteristics of the payload. Conducting these tests 
as soon as the proposed configuration is developed will provide sufficient time 
to permit the redesign or modification to structural supports, if the test 
results indicate that it is necessary. Sufficient advanced notification will 
enable the integrator to complete the interface hardware modifications prior 
to initiation of experiment integration. 
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Thermal. Two principal thermal environments to which the Spacelab will 
be exposed are (1) enclosed Orbiter payload bay during launch and boost to 
orbit (experiments not operating in a stowed configuration), and (2) Orbiter 
operations on orbit with the payload doors open (experiments deployed and 
operating) . 

During the launch boost period, heat will be transferred by radiation, 
conduction and convection and will involve interaction among the experiments, 
Spacelab modules, and Orbiter structure as well as the active thermal control 
systems . 

During orbital operations, experiments mounted on the pallet will be 
operating in a vacuum environment; heat transfer by radiation to deep space 
and from the sun or earth must be evaluated. The Spacelab active thermal 
control system can provide cooling by means of coldplates. Air circulation 
in the SM/EM includes ducting in the equipment racks. Considerable experi- 
ence has been acquired on heat transfer characteristics in the space environ- 
ment, and it is assumed that the Spacelab modules and individual experiments 
will have undergone thermal analysis and thermal environmental testing to the 
defined mission environments during development. With these data available, 
together with thermal data from previous flights, it will be possible to verify 
the capability of the integrated experiment equipments to perform in the mission 
thermal environment by analysis. Data from previous flights will be especially 
significant because direct examination of the experiment hardware upon return 
from the space environment can be accomplished with the Spacelab/Orbiter sortie 
mission mode of operations. 

Final verification of the capability of the Orbiter-Spacelab to maintain 
required thermal control of experiments in the Spacelab modules or the experi- 
ment equipment canisters, where sea- level ambient pressure and nominal temper- 
atures are maintained, will be demonstrated by functional testing during 
experiment integration, Spacelab integration, and Orbiter-cargo integration. 
Similarly, verification of the active thermal control system interfaces with 
coldp late-mounted equipment will be verified during the functional tests of 
those three integration levels. 

Vacuum. Experiments mounted on the pallet in the Orbiter payload bay will 
be exposed to space vacuum environment during the orbital portion of the 
mission. It is assumed that all pallet-mounted experiment hardware will be 
tested for operation in this environment during development. It is also 
assumed that the Spacelab modules will be tested in a thermal/vacuum chamber 
during development, so that a leak test during Spacelab integration will pro- 
vide adequate verification of compatibility with the space vacuum environment. 

Electromagnetic Interference. Electromagnetic interference (EMI) emission 
and susceptibility limits are established by the Orbiter/Spacelab programs for 
all electrical/electronic equipment, including payloads. It is assumed that 
the carrier systems and individual experiments will demonstrate compliance 
with these requirements by testing during development. The Orbiter/Spacelab 
programs require a 6-dB margin between interference and susceptibility levels 
for each function for electromagnetic compatibility. 
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It is neither practical nor necessary to conduct quantitative EMI testing 
throughout the hardware integration process. Individual experiment systems 
would have been evaluated for internal EMI effects; therefore, only integrated 
operations need be evaluated for EMC. In general, the primary source of EMI 
is power switching transients. All anticipated combined operations, including 
power switching, should be evaluated for EMC during checkout. Effective veri- 
fication of EMC can be achieved by noting the effects of integrated operations 
on individual experiment response to commands and data during experiment 
integration, Spacelab integration and, finally, Orbiter-cargo integration. 

This requires that functional testing be designed to monitor significant func- 
tions while exercising all switching functions in the integrated experiment 
configuration, with additional interfaces becoming involved at successive 
phases of the ground processing cycle. 

Humidity , Dust t and Corrosive Atmosphere . This environment should not 
present a problem during the experiment integration processing cycle because: 

• Experiment installation, integration, and checkout activities with 
the Spacelab will be conducted in a controlled laboratory environ- 
ment during the various phases of ground processing, and flight 
hardware will be protected from adverse ambient environments 
during shipping. 

• Spacelab installation in the Orbiter payload bay, and integration 
verification tests, will be conducted in the controlled atmosphere 
of the Orbiter Maintenance Facility after which the payload bay 
will be closed. 

• The Orbiter payload bay will be supplied with filtered, conditioned 
air or dry N2 gas during the remainder of prelaunch, launch, and 
boost operations. 

Verification Approach . The various environments to which the integrated 
ATL/Spacelab will be exposed during a mission were identified previously. 
Verification of ATL/Spacelab compatibility with mission environments can be 
accomplished by several methods and at various stages of development and 
the ground processing cycle. Verification methods considered include the 
following : 

• Similarity with previously flown or tested hardware and 
payload configurations. 

• Analysis, using a math model verified by test or previous 
flights. 

• Testing a similar configuration. 

• Testing the actual flight hardware configuration. 

Verification of environmental compatibility is considered at the various 
program phases from development to Orbiter-cargo integration. But, in pre- 
vious programs, the trend was (see Figure 4.1-11) to utilize at least a 
first-flight (assembly qual/carrier qual/vehicle qual) qualification of the 
integrated experiment/ carrier interface. In multiple-flight programs, until 
the environment was adequately defined, vibra-acoustics , thermal-vacuum 
and shock-acceleration compatibilities were established by empirical testing. 
EMC required repetitive testing in addition to similarity analyses. 
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In contrast to previous programs, examination of the Shuttle/Spacelab 
development program indicates that the environment definition will be accur- 
ately defined. Math models will be updated based upon both qualification 
tests and actual flight data (see Figure 4.1-12). Initial Spacelab flights 
may require some integrated environmental testing. Simulated experiment 
equipment could be used for these tests; however, in the steady-state ATL 
program, no integrated environmental testing (other than EMI) is recommended. 
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Figure 4.1-12. ATL-Induced Environment Definition 


It is recommended that, as far as the integrated payload is concerned, 
environmental qualification be accomplished by analysis or similarity, and 
the individual experiment equipments be selected or designed to operate 
within the defined environment. 


As mentioned previously, EMI testing during the integration cycle is the 
only environmental test recommended. The current technology is inadequate to 
control or predict the potential interference/interaction of equipments. The 
recommended ATL experiments environmental verification testing is summarized in 
Table 4.1-10. 

The test and operations sequences described reflect inclusion of only EMI 
testing during integration. Manpower estimates, including documentation 
requirements and responsibility assignments, that are described subsequently 
reflect the systems analysis effort required to specifically and uniquely 
define the other environments for each mission. 
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Table 4 . 1 - 10 . ATL In-Process Requirements Summary 


VI BRA-ACOUSTICS 

1 NOI VI DUAL 
EXPERIMENTS 

INTEGRATED 

PAYLOAD 

COMMENTS 

TEST 

ANALYSIS 

INTEGRATED ANALYSIS 
WITH MATH MODEL 

THERMO-VACUUM 

TEST 

ANALYSIS 

INTEGRATED ANALYSIS 
WITH THERMO PROFILE 
MODEL 

SH0CK-ACCEL 

TEST/ANALYSIS 

ANALYSIS 

FLIGHT SAFETY REQUIRES 
STRESS ANALYSIS 

GROUND TRANSPORT IS 
PRIMARY CONCERN 

RF 1 /EMI 

TEST/ANALYSIS 

TEST 

INTEGRATED EMI 
ENVIRONMENT NOT 
ACCURATELY PREDICTABLE 


Specification of the environments and system analysis of the integrated 
configurations are the primary activities that the payload integrator should 
conduct in direct support of experiment equipment development. Individual 
equipment qualification test results should be coordinated with the payload 
integrator. 

Operational Test Requirements 

The processing of flight hardware could influence test/retest requirements 
as well as installation/assembly procedures. The working environment (clean 
room) was evaluated to determine that a reasonable sequence of the buildup 
operations was provided. The analysis was made to determine whether any of the 
assembly or test/integration operations would be delayed to a later/higher 
assembly level by cleanliness requirements. Shipping/transportation was also 
evaluated because the adopted technique could also result m significant retest. 

Impact of Cleanliness Constraints 

Cleanliness requirements could cause the installation of experiment equip- 
ment to be out of sequence with respect to the appropriate assembly level. 

That is, if only an air-conditioned environment were available during Level III 
integration, some experiment installation and checkout may have to be postponed 
until a later assembly level (possibly Level I integration) . This delay would 
be very disruptive to the optimum test schedules and hardware flows. Delaying 
the installation of experiments from Level III integration to Level I may have 
the impact of invalidating some of the previously established interfaces and 
result in additional resource expenditures and schedule extension for retest. 
Installation of experiment equipment on the pallet segments may be severely 
constrained after Level III integration has been completed. Center-of-gravity 
constraints and, thus, equipment-mounting provisions, may dictate a specific 
assembly sequence. Therefore, a consistent cleanliness capability should be 
maintained throughout the processing cycle. 

It is anticipated that during the operational period of the Spacelab, 
numerous payloads will require a 100,000 class clean room environment. Some 
sensors will require even more stringent clean room environments. As it is 
impractical to maintain the Orbiter cargo bay at levels more, s trin gent than 
100,000 class, this level was baselined for all hardware processing facili- 
ties. It should be noted that the ATL experiments of the three baseline 
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payloads used In this study could be processed in a standard air-conditioned 
environment. But the more stringent 100,000 cleanliness level was imposed 
to reflect the general applicability of the processing concepts. Thus, 100,000 
class environment must be maintained during Levels III and II activities. The 
planned Orbiter Processing Facility at KSC that will be used for Level I inte- 
gration includes 100,000 class provisions. During preparations for transporta- 
tion, bagged enclosures for experiments, airlocks and special transportation 
canisters (scrubbed down after each use) will be utilized to meet the required 
cleanliness level. Shipping time estimates include these precautionary measures. 

Impact of Shipping/Transportation 

V Because of the size of the various levels of assembly, the method selected 

for shipping/transportation was significant. If previously verified connections 
were broken to facilitate the shipment of Spacelab hardware elements, then re- 
verification after shipment would be required. Alternate techniques were invest- 
igated for the shipment of both modular and assembled configurations. Figure 
4.1-13 represents the various combinations o£ hardware and transportation modes. 
Barge or ship transportation is costly, time-consuming, and has limited utility; 
i.e., for land-locked sites, alternate modes are necessary. In the case of the 
ATL, this method could be used; however, when other potential Spacelab users are 
considered (e.g., Ames, European), the time and costs become excessive. For 
these reasons, barge/ship transportation modes for any combination of hardware 
was rejected as being unrealistic. 



Figure 4.1-13. Spacelab Transportation Trades 
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Any assembled combination of the support module, experiment module and/or 
pallet precludes both rail or truck transportation modes because the present 
diameter of the modules is 13 feet, 7 inches, which makes the assembled or 
single-element dimensional characteristics exceed both rail and highway 
restrictions . 

Thus, the remaining option open foT transporting the assembled Spacelab 
— air transportation — is the only practical method. Referring to Figure 
4.1-13, it is noted that the Guppy is not a prime candidate due to its non- 
availability. The Shuttle program has established the feasibility of using 
a 747-type aircraft for a piggyback shipment approach for the Orbiter. There- 
fore, the 747 piggyback approach is the recommended transportation mode for 
the assembled Spacelab. Pallet-only Spacelabs could be shipped in the C-5A 
aircraft if the combined height of the pallet and pallet-mounted sensors is 
less than 13.5 feet. 

Modular shipment of Spacelab elements is feasible since their length of 
10 feet could be accommodated by rail, truck, or air (C-5A) by proper orienta- 
tion and positioning during loading operations. It should be recognized- that 
the ground transportation mode selected should be reviewed for compatibility 
with the vibration/shock constraints of the equipment being shipped. Also, 
modular shipment implies breaking interfaces between equipment items previously 
tested, which may result in stringent retest requirements with potential impact 
on processing cycle time. 

Figure 4.1-14 presents the modular Spacelab transportation trade from 
two points of view: post-flight shipment and pre-flight shipment. 


ALL MOMS POSSIBLE 
WHERE NOT SPECIFICALLY 
CONSTRAINED BY 
VIBRATION/SHOCK OF 
GROUND MODES 


PIGGYBACK (747) 

OR C5A 

ATL APPROACH 

• INTERFACE INTEGRITY MAINTAINED 
•MINIMUM RETEST 

• SENSOR HEIGHT CONTRAINT NO MORE 
STRINGENT THAN FOR ORBITER 

Figure 4.1-14. Modular Spacelab Shipment 





4-45 


SD 74-SA-0156 









Space Division 
Rockwell International 





During post-flight operations, the integrity of the interfaces are of 
less concern; disassembly operations of the racks, rack/pallet, and pallet/ 
igloo elements can be accomplished at the launch site. With sensor removal 
from the pallets at the launch site, all transportation modes are possible 
including the C-5A for air transport. However, removal of the sensors is not 
recommended because of the potential requirement for special-handling GSE, 
increased packaging requirements, and increased processing time. 

Pre-flight shipment of integrated rack/pallet or pallet-only module 
configurations should be accomplished only by air transportation. Limiting 
the height of pallet-mounted sensors, for ground transportation reasons, to 
values less than those imposed by the Orbiter is not acceptable. Therefore, 
the use of the 747 piggyback is the baseline approach for purposes of general 
applicability. 

It is recognized that the rack/floor sets will fit into the C-5A, and 
numerous integrated pallets will be less than the C-5A height constraint of 
13.5 feet. ESRO/ERNO has identified a special GSE item that permits the tilt- 
ing of the end bulkhead of the SM or EM to an overall height of less than 13.5 
feet. Thus, rack/pallet interfaces that are connected through the end bulkhead 
and have been verified during Level III integration can be maintained during 
shipment. In those cases where combined pallet-sensor height is less than 
13.5 feet, the use of the C-5A as the transport aircraft is practical. 

Composite Requirements Matrix 

The test and operations requirements for the processing of Spacelab pay- 
loads were developed through an iterative top-doun and bottom-up approach. 
Rudimentary, skeletonal timelines of the major anticipated tests were estab- 
lished first (top doun) . As the preferred checkout approach and test phil- 
osophy were developed, the major tests and associated subordinate tests were 
detailed. After all identifiable tests and operations were define, a summa- 
tion to an integrated flow level was accomplished ( bottom up). Thus, the test 
and operations sequences were developed concurrently with the test requirements. 

A composite set of the test and checkout requirements (TCR) for the 
processing of the complete Spacelab is presented in Table 4.1-11. A similar 
listing of the requirements for the pallet-only configuration is presented in 
Table 4.1-12. Both pre-flight and post-flight test activities are defined for 
levels of integration/disassembly/refurbishment. These TCR listings reflect 
the following guidelines, assumptions, and processing optimizations. 

• Developmental, environmental, and performance capability tests of 
Orbiter, Spacelab, and individual experiment systems were conducted 
prior to the initiation of the integration and checkout of payload 
flight hardware. 

• Level IV integration, individual experiment system acceptance 
testing, is accomplished prior to receipt of experiment equip- 
ments at the payload integration site. This integration may 
occur with the experiment equipments mounted in flight racks 

, if a dedicated rack/rack set is feasible. However, as dedi- 

cated rack/rack sets are not always available for a single 
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Table 4. 1-11. Complete Spacelab TCR Matrix 


TEST/CHECKOUT REQUIREMENT 


VERIFY PLUGS-OUT CONTINUITY OF RACKS/EXPERIMENTS/EQUIPMENT 

LEAK-CHECK FLUID CONNECTIONS AT AFT BULKHEAD & PALLET INTERFACES 

VERIFY SM l/F SIMULATOR MECH/ELECT CONNECTIONS WITH FACILITY 

VERIFY SM l/F SIMULATOR/RACKS/PALLET INTERFACES 

VERIFY SERV UNIT FLOW 6 CONTROL TO RACK/PALLET COOLANT LOOPS 

PERFORM BUS ISOLATION TESTS OF RACKS/EXPERIMENTS/PALLET 

PERFORM ELECTRICAL POWER DISTRIBUTION TEST 

VERIFY CAUTION /WARNING CIRCUITRY 

PERFORM COMPUTER & INSTRUMENTATION SYSTEMS SELF-CHECKS 

VERIFY DMS COMMAND S CONTROL £ PERIPHERAL EQUIPMENT 

VERIFY GROUND DATA BASE (GDB) COMPATIBILITY VIA GDB UMBILICAL 

VERIFY RACKS/EXPERIMENT AUXILIARY EQU I PHENT— CCTV , INTERCOM, ETC 

VERIFY READINESS OF EXPERIMENT OR SUPPORT EQUIPMENT FOR ACfllMTION 
ACTIVATE CONTROL £ DISPLAYS £ SUPPORT EQUIPMENT 

VERIFY PERFORMANCE OF C/D CONSOLE DURING EXPERIMENT FUNCTIONAL CHECKOUT 
VERIFY OPERATION OF PALLET-MOUNTED DEPLOYABLE EXPERIMENT EQUIPMENT 
VERIFY OPERATION OF RACK-MOUNTED MECHANICAL EXPERIMENT EQUIPMENT 
VERIFY FUNCTIONAL OPERATION OF EXPERIMENTS/SUPPORT EQUIPMENT 
VERIFY DATA PROCESSING/RECORDING EQUIPMENT DURING EXPERIMENT CHECKOUT 
CONDUCT EMI/RFI TESTS 




CONDUCT £ VERIFY ALL COMPLETE SPACELAB ELECTRICAL/MECHANICAL INTERFACES 

SERVICE £ VERIFY COOLANT FLOW THROUGH GSE 

VERIFY ORBITER INTERFACE SIMULATOR OPERATIONAL CAPABILITY 

PERFORM COMPLETE SPACELAB BUS ISOLATION TEST 

CONDUCT COMPLETE SPACELAB ELECTRICAL POWER DISTRIBUTION TESTS 

VERIFY COMPLETE SPACELAB CAUT I ON/UARN I NG CIRCUITRY 

CONDUCT COMPLETE SPACELAB COMPUTER SELF-CHECKS 

VERIFY COMPLETE SPACELAB DMS COMMAND/CONTROL £ PERIPHERAL EQUIPMENT 
VERIFY COMPLETE SPACELAB AUXILIARY EQUI PMENT— CCTV , INTERCOM, LIGHTING, ETC 
CHECK OUT SIGNAL DISTRIBUTION VIA SM-ORBITER UMBILICAL 
VERIFY GOB OPERATION VIA GDB UMBILICAL 

CONDUCT FUNCTIONAL C/O OF COMPLETE SPACELAB SUPPORT SYS/EXPMT EQUIP INTERFACES 
CONDUCT EMI SSI VI TY TESTS OF COMPLETE SPACELAB EXTERIOR SURFACES 
CONDUCT COMPLETE SPACELAB 2l(-HOUR PRESSURE DECAY LEAK CHECK 

CONDUCT COMPLETE SPACELAB WEIGHT/BALANCE TESTS 

PERFORM COMPLETE SPACELAB/ORB I TER PRE-INSTALLATION INTERFACE VERIF TESTS 
SERVICE COMPLETE SPACELAB WITH NON-HAZARDOUS FLUIDS £ LOW-PRESSURE GASES 
VERIFY ORBITER READINESS TO ACCEPT COMPLETE SPACELAB 
PERFORM ORB I TER/COMPLETE SPACELAB INTERFACE VERIFICATION TESTS 
PERFORM ORBITER INTEGRATED TEST (OIT) 

CONDUCT COMPLETE SPACE LAB/ORB I TE R EMI/RFI TESTS 

PERFORM ABBREVIATED LEAK CHECKS 
A TUNNEL 
B TUNNEL HATCH 

C COMPLETE SPACELAB INTERFACE 

PERFORM ORDNANCE INSTALLATION TESTS 

CONDUCT COMPLETE SPACELAB FINAL PRELAUNCH TESTS 

PERFORM COMPLETE SPACELAB HAZARDOUS MATERIALS LOADING TESTS 

REFURBISH RACKS/PALLET 

A DRAIN, FLUSH, DRY E CAP COOLANT SYSTEM 
B REMOVE RACKS/EXPERIMENTS 
C REFURBISH RACKS 

D VERIFY OPERABILITY OF FLUID SYSTEM COMPONENTS 

REFURBISH SUPPORT SYSTEMS AND SM/EM ASSEMBLY 

A DRAIN, FLUSH, DRY £ CAP COOLANT SYSTEM 
B VERIFY OPERABILITY OF FLUID SYSTEM COMPONENTS 
C VERIFY OPERATION OF DMS COMPONENTS 

E VERIFY OPERATION OF CPSS (AIRLOCKS, IPS, ETC ) AS REQUIRED 
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Table 4.1-12. Pallet-Only TCR Matrix 


TEST/CHECKOUT REQUIREMENT 


VERIFY PLUGS-OUT CONTINUITY OF EXPMT IGLOOS/EXPERIMENTS/EQUIPMENT 
LEAK-CHECK FLUID CONNECTIONS AT PALLET/ I GLOO/EXPERI MENT INTERFACES 


VERIFY SUPPORT SYSTEMS IGLOO G ORBITER SIM SETS ELECT/MECH CONNECTIONS W/FACILITY 
VERIFY SUBSYSTEMS IGLOO SIM/ORBITER SIM/EXPERIMENT IGLOO/PALLET INTERFACES 
VERIFY SERVICING UNITS FLOW 6 CONTROL TO PALLET/IGLOO COOLANT LOOPS 
PERFORM BUS ISOLATION TESTS OF PALLET/IGLOO EXPERIMENTS N 

PERFORM ELECTRICAL POWER DISTRIBUTION TESTS 
VERIFY CAUTION/WARNING CIRCUITRY 

PERFORM COMPUTER 6 INSTRUMENTATION SYSTEM SELF-CHECKS 

VERIFY OMS COMMAND/CONTROL 6 PERIPHERAL EQUIPMENT 

VERIFY PALLET/IGLOO AUXILIARY EQUIPMENT — CCTV, INTERCOM, ETC 

VERIFY GROUND DATA BASE COMPATIBILITY WITH GROUND DATA BASE (GDB) UMBILICAL 


VERIFY READINESS OF EXPERIMENTS 6 SUPPORT EQUIPMENT FOR ACTIVATION 

ACTIVATE PALLET/IGLOO, CONTROL G DISPLAYS G SUPPORT EQUIPMENT 

VERIFY PERFORMANCE OF CGD CONSOLE DURING EXPERIMENT FUNCTIONAL TESTS 

VERIFY OPERATION OF PALLET-MOUNTED DEPLOYABLE EXPERIMENT EQUIPMENT 

VERIFY OPERATION OF EXPERIMENT/IGLOO MOUNTED MECHANICAL EQUIPMENT 

VERIFY FUNCTIONAL OPERATION OF EXPERIMENTS/SUPPORT EQUIPMENT 

VERIFY DATA PROCESSING/RECORDING EQUIPMENT DURING EXPERIMENT CHECKOUT 

CONDUCT EMI/RFI TESTS 


CONDUCT PALLET/SUBYSTEMS IGLOO ELECTRICAL BONDING TESTS AFTER P/SS IGLOO MATING 
CONDUCT 6 VERIFY PALLET/SUBSYSTEMS IGLOO ELECTRI CAL/HECHAN I CAL INTERFACES 


SERVICE 6 VERIFY COOLANT FLOW THROUGH GSE 

VERIFY ORBITER INTERFACE SIMULATOR OPERATIONAL CAPABILITY 

PERFORM PALLET/SUBSYSTEMS IGLOO BUS ISOLATION TESTS 

CONDUCT PALLET/SUBSYSTEMS IGLOO ELECTRICAL POWER DISTRIBUTION TESTS 

VERIFY PALLET/SUBSYSTEMS IGLOO CAUTI ON/WARN I NG CIRCUITRY 

CONDUCT SUBSYSTEMS IGLOO COMPUTER SELF-CHECKS 

VERIFY SUBSYSTEMS IGLOO OMS COMMAND/CONTROL G PERIPHERAL EQUIPMENT 
VERIFY PALLET/SUBSYSTEMS IGLOO AUXILIARY EQUI PMENT--CCTV, INTERCOM, ETC 
VERIFY SIGNAL DISTRIBUTION VIA SUBSYSTEMS I GLOO/ORB I TER UMBILICAL 
VERIFY GROUND DATA BASE OPERATION VIA THE GDB UMBILICAL 

CONDUCT FUNCTIONAL CHECKOUT OF IGLOO SUPPORT SYSTEMS/EXPERIMENT EQUIP INTERFACES 
CONDUCT EMISSIVITY TESTS OF PALLET/SUBSYSTEMS IGLOO EXTERNAL SURFACES 
CONDUCT SUBSYSTEMS IGLOO 2A-HOUR PRESSURE DECAY LEAK CHECK 
CONDUCT PALLET/SUBSYSTEMS IGLOO WEIGHT/BALANCE TEST 


PERFORM PALLET/ 1 GLOO/ORB I TER PRE-INSTALLATION INTERFACE VERIFICATION TESTS 

SERVICE PALLET/IGLOO WITH NON-HAZARDOUS FLUIDS G LOW-PRESSURE GASES 

VERIFY ORBITER READINESS TO ACCEPT PALLET/IGLOO 

PERFORM PALLET/ 1 GLOO/ORB I TER INTERFACE VERIFICATION TEST 

PERFORM ORBITER INTEGRATED TEST 

CONDUCT ORB I TER/PALLET/IGLOO EMI/RFI TESTS 

PERFORM ORDNANCE INSTALLATION TESTS 


CONDUCT FINAL PALLET/IGLOO PRE-LAUNCH TESTS 
PERFORM PALLET/IGLOO HAZARDOUS MATERIALS LOAD TESTS 


REFURBISH SUPPORT SYSTEMS IGLOO 

A DRAIN, FLUSH, DRY G CAP COOLANT SYSTEM 
B VERIFY OPERABILITY OF FLUID SYSTEM COMPONENTS 
C INSPECT/REPAIR ELECT CABLES/CONNECTORS G FLUID LINES 
D REFURBISH G VERIFY OPERATION OF THE DMS COMPONENTS 
E INSPECT/REPAIR SUBSYSTEM IGLOO MATING SURFACES 
F INSPECT/REPAIR SUBSYSTEM IGLOO STRUCT STRESS/DAMAGE 


REMOVE EXPERIMENTS, CABLES, LINES G BRACKETS FROM PALLET/IGLOO 


REFURBISH/RECONFIGURE PALLET AND IGLOOS 

A DRAIN, FLUSH, DRY G CAP COOLANT SYSTEM 
B VERIFY OPERABILITY OF FLUID SYSTEM COMPONENTS 

C VERIFY OPERABILITY OF PALLET/IGLOO POWER CONDITIONING SYSTEM 

0 INSPECT/REPAIR PALLET/IGLOO ELECTRICAL CABLES/CONNECTORS 
G FLUID LINES 

E INSPECT/REPAIR PALLET/IGLOO MATING SURFACES 

F INSPECT/REPAIR PALLET STRUCT STRESS DAMAGE 
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experiment system the timelines developed in this study reflect 
an installation and functional checkout of experiment equipments 
in rack/rack sets at the payload integration site. 

• A Spacelab support systems simulator will be used during exper- 
iment integration (Level III) in all processing concepts. Sim- 
ulators will be used to reduce ON- time of the flight hardware; 
negate the requirement for shipment of flight support systems 
from the launch site in Concepts II, III, IV, VI, VII, and VIII; 
and reduce the complement of support modules and systems igloos 
required to support the anticipated Spacelab traffic model. 

• An Orbiter interface simulator will be used during Spacelab 
integration (Level II) in all processing concepts. 

• Level III experiment integration tests are confined to integra- 
tion and functional checkout of experiment systems which include 
the complete experiment complement, racks, rack sets, and exper- 
iment support equipment. The principal investigator (PI) is 
assumed to play a strong role during these tests. Minimal 
allowance for troubleshooting individual experiments has been 
made in the formulation of the test timelines. It is presumed 
that the individual experiment systems have been debugged, and 
that only integration problems between experiments might be 
encountered. 

• Operation of deployment booms and equipment specifically 
designed for zero-g conditions may be required during checkout. 
Special GSE to accomplish this type of checkout will be furn- 
ished by the PI. 

8 Level II integration tests shall consist of a functional check- 

out_of the interfaces b etween the integrated experiment equip- 
ments and the Spacelab support systems. When applicable, 
compatibility of Orb iter-experiment systems interfaces will be 
verified by utilizing the Orbiter interface simulator. Orbiter- 
Spacelab interface compatibility demonstrations are not required 
during the operational era of these two elements. 

• On-board checkout capability will be utilized throughout the 
hardware integration process. Functional checkouts that reflect 
planned flight operations will be emphasized. 

8 Repeat testing will be minimized. Functional tests, even after 
major equipment moves, will be limited to verification of inter- 
faces established at the next assembly level. Verified flight 
interfaces need not be interrupted for shipping/transportation 
purposes . 
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• Integrated payload environmental compatibility will be verified/ 
certified by analysis and similarity to previous payloads, except 
for EMI.' EMC will be assessed during combined systems tests that 
are part of Level III integration activities. 

• Level I integration includes Orbiter-cargo integration, launch, 
landing, and Orbiter-cargo disassembly activities. The integra- 
ted payload/Spacelab design, test requirements, installation/ 
removal procedures, and test procedures shall conform to the 
schedule constraints of the Shuttle turnaround plan. 
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4.2 TEST FLOW DEVELOPMENT 


The test flows for both the complete Spacelab and the pallet-only config- 
urations were developed utilizing the three-step method illustrated in Figure 
4.2-1. 


TEST 6 OPERATIONS FLOW CHARTS 
(INTEGRATED FLOWS) 



Figure 4.2-1. T&O Test Flow Development 


Step 1 established a top-level functional block diagram for each of the 
eight processing concepts. These block diagrams were derived from hardware 
processing scenarios that were synthesized to identify the assembly, test, 
and transportation activities associated with each concept. The scenarios 
and, thus, the block diagrams, were sequenced in the required order of accomp- 
lishment and reflect all hardware ground processing activities. Site location, 
involved centers, and integration levels were identified on the diagrams. 

Step 2 consisted of the expansion of the functional blocks to at least 
two levels of detail: (1) detailed flows, and (2) activity data sheets. This 
expansion is illustrated in Figure 4.2-1 for function block 8.0, Experiment 
Integration. The detailed flows were time-sequenced to provide the basis for 
determination of the total duration of the processing cycle. At this level 
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of detail, the only overlapping and/or paralleling of effort considered was 
within the activities of .a functional block. Activity data sheets were pre- 
pared that provide a narrative description of each of the activities in the 
detail flows. The activity data sheets provide the basis for estimating 
manpower, GSE, and facility requirements for each test and operations activity. 
The descriptors and resource requirement definitions of the activity data 
sheets facilitated the overlap/parallel scheduling of some test and operations 
tasks . 

Step 3 time-phased the individual detail flows into an integrated test 
and operations sequence for each concept. With the descriptors and resource 
requirement definitions of the activity data sheets, additional overlapping/ 
paralleling of activities was accomplished at the functional block level. 

The integrated flows reflect the optimized cycle for the pre-flight and post- 
flight processing of all the flight hardware. 

The following paragraphs define how the individual test and operations 
activities were determined, and the process by which they were combined to 
form the composite set of integrated flows for both the complete Spacelab and 
the pallet-only processing concepts. 

COMPLETE SPACELAB 

The complete Spacelab data, presented in this section, relate to the five 
concepts previously established under "Concept Development" (Volume I, Section 
3.0). The detailed flows and activity data sheets for the complete Spacelab 
are presented in Appendix D (Part I). The following paragraphs illustrate the 
test flow development for each of the five complete Spacelab concepts. 

Functional Block Diagram 

Scenarios describing all of the test and operations activities were made 
for each of the five complete Spacelab processing concepts. Figure 4.2-2 
relates to Concept IV, and is an example of the scenarios developed. This 
scenario illustrates the piggyback transport method utilizing a 747-type air- 
craft. However, the sequence of operations is equally applicable to the C-5A 
transport method with very minor time and sequence variations. From these 
scenarios, the complete set of functional blocks (for all concepts) were 
defined. There are 22 functional blocks that were identified as being required 
to complete the test and operations activities for all five complete Spacelab 
concepts. Table 4.2-1 contains a listing of all 22 possible functional blocks 
including their titles and respective WBS numbers. The blocks are not numer- 
ically listed, but are arranged by WBS number within the three levels of 
integration. 

Block 13.0, Mission Operations } was included as a reference for complete- 
ness of the processing cycle. It includes those activities from Shuttle lift- 
off through Orbiter touchdown. The operations for this block were not expanded 
because they are not a part of the integration and checkout activities. All 
22 functional blocks are not utilized in each of the complete Spacelab process- 
ing concepts. The explanation of the baseline for each concept will illustrate 
the applicability of a functional block to a particular concept. 
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Table 4.2-1. Complete Spacelab Functional Block Identification 


1 


BLOCK 



WBS NUMBER 

NO. 

FUNCTIONAL FLOW TITLE 


60-00-50-1 .0 

1.0 

EXPERIMENT SHIPMENT 


-2.0 

2.0 

EXPERIMENT INSTALLATION 


-3.0 

3.0 

CONNECT SM INTERFACE SIMULATOR 

1 1 1 

-4.0 

4.0 

EXPERIMENT INTEGRATION 

-5.0 

5.0 

GSE DISCONNECT 


-6.0 

6.0 

RACKS/PALLET SHIPMENT 


-18.0 

18.0 

RACKS/PALLET SHIPMENT 


-19.0 

19.0 

REFURBISH RACKS/PALLET 


-20.0 

20.0 

EXPERIMENT SHIPMENT 


-22.0 

22.0 

POST-REFURBISHMENT RACKS/PALLET SHIPMENT 


63-00-50-7.0 

7.0 

MATE RACKS/PALLET-EM/SM SHELLS 


-8.0 

8.0 

COMPLETE SPACELAB INTEGRATION 

1 1 

-9.0 

9-0 

COMPLETE SPACELAB SHIPMENT TO LAUNCH SITE 

-10.0 

10.0 

COMPLETE SPACELAB OFFLOAD 


-15.0 

15.0 

COMPLETE SPACELAB MOVE TO MS0B 


-16.0 

16.0 

COMPLETE SPACELAB SHIPMENT FROM LAUNCH SITE 


-17.0 

17.0 

DEMATE EM/SM SHELLS 


-21.0 

21.0 

REFURBISH SUPPORT SYSTEMS S EM/SM SHELLS 


66-00-50-11.0 

1 1.0 

0RBITER CARGO INTEGRATION 


-12.0 

■1MISS 

LAUNCH OPERATIONS 

i 

-13.0 

■RH3 

MISSION OPERATIONS (REFERENCE) 


-14.0 

■ 

POST-FLIGHT OPERATIONS 


Concept I 

This concept utilizes the IC as the owner of all the complete Spacelab 

hardware elements and the location for_ both Levels III (experiment) and II 

(Spacelab) integration. Figure 4.2-3 illustrates the specific T&O tasks 
required for the ground processing of Concept I. The lines connecting the 
blocks describe the sequence of operations and the hardware flow paths. 

Concept I operations begin with Block 1.0, Experiment Shipment from the user. 
The next four hlocks (2.0, 3.0, 4.0, 5.0) are related to Level III (experiment) 
integration. Within each of the functional block number boxes, there is a 
Roman numeral that indicates which level of integration is supported by that 
particular activity (i.e., Block 8.0 contains the activities related to Level 
II — Spacelab integration; and Block 5.0, GSE Disconnect , contains those oper- 
ations related to Level III — experiment integration) . The caption at the 
top of each functional block identifies the center responsible for the accomp- 
lishment of that particular block. Above four of the blocks (1.0, 9.0, 16.0 
and 22.0) there are two centers shown because these four blocks pertain to 
the shipment of the complete Spacelab hardware end items between centers. 

For example. Block 9.0 is shown to involve both the LS/IC because Block 9.0 
contains the test and operations activities relating to the shipment of the 
integrated (Level II — completed) complete Spacelab from the IC to the LS. 

As discussed previously, not all tasks contained in Table 4.2-1 are utilized 
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in each of the five complete Spacelab concepts. A comparison of Figure 4.2-3 
and Table 4.2-1 will show that Blocks 6.0, 15.0, 18.0, and 22.0 are not 
required in Concept I for the following reasons. 

Block 6.0 - Racks /Pallet Shipment. The racks and pallet are mated with 
and installed m the SM/EM assembly following experiment integration, and the 
complete Spacelab is shipped to the launch site from the integration center 
in a near-flight configuration. 

Block 15.0 - Complete Spacelab Move to MSOB. Since the complete Spacelab 
integration was performed at the integration center, after Orbiter landing the 
complete Spacelab is removed from the Orbiter cargo bay m the OPF and shipped 
directly to the IC without processing through the MSOB. 

Block 18.0 - Racks/Pallet Shipment. The racks and pallet are shipped 
from the LS to the IC as part of the complete Spacelab configuration; there- 
fore, no separate shipment is required. 

Block 22.0 - Post-Refurbishment Racks/Pallet Shipment. This task applies 
only to Concept III, where refurbishment of the racks and pallet occurs at the 
IC and they are shipped to the user site for Level III integration. 

Concept II 

Following the procedures established above for Concept I, the specific 
tasks from the total set of processing activities (Table 4.2-1) that apply 
to Concept II are shown in Figure 4.2-4. It should be noted that Blocks 9.0, 
10.0, 16.0, and 22.0 do not apply for the following reasons. 

Block 9.0 - Complete Spacelab Shipment to Launch Site. Following exper- 
iment integration, only the rack/pallet assembly is shipped to the launch 
site for integration with the SM/EM assembly. The SM/EM assembly remains at 
the-LS- — — _ — _ _ __ _ _ 

Block 10.0 - Complete Spacelab Offload. Complete Spacelab offload does 
not apply for this concept since the complete Spacelab is not shipped to 
the launch site. 

Block 16.0 - Complete Spacelab Shipment from Launch Site. The SM/EM 
assembly remains at the launch site; only the rack/pallet assembly is shipped 
to the IC. 

Block 22.0 - Post-Refurbishment Racks/Pallet Shipment. As previously 
indicated in Concept I, this task applies only to Concept III. 

Concept III 

The tasks from Table 4.2-1 that apply to Concept III are shown in Figure 
4.2-5. From the figure, it is evident that Blocks 9.0, 10.0, and 16.0 do not 
apply for the same reasons specified for these tasks under Concept II. 
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Concept IV 

The tasks from Table A. 2-1 that apply to Concept IV are shown in Figure 
A. 2-6. It is seen that Blocks 9.0, 10.0, 16.0, and 22.0 are not applicable 
to this concept for the reasons stated under Concept II. In Block 18.0, the 
rack/pallet assembly is shipped to the user site instead of the IC. 

Concept V 

Table A. 2-1 tasks, applicable to Concept V, are shown in Figure A. 2-7. 
Blocks 6.0, 15.0, 18.0 and 22.0 do not apply for the reasons given under 
Concept I for these same tasks. Note that in Concept V the user center 
assumes the role of the IC in Concept I. 

Detail Flows 


Figure A. 2-8 is an example of one of the detail flows which shows the 
level at which the tests/operations are defined for each of the functional 
blocks. Each asterisk shown between the integers at the top of the detail 
flows represent one hour of an 8-hour work day utilized as the baseline for 
the study. Also, the asterisks in front of each task title represent one 
hour. Thus, the time estimate for each task is also indicated. Where 
applicable, during Orbiter/Spacelab operations at the launch site, there are 
periods of time when the complete Spacelab is operating under the 16-hour/day 
Orbiter schedule. Where they occur, each of these periods is marked on the 
affected detail flow. Utilizing the asterisks above the individual task 
description/titles, and the asterisks preceding the title, the estimated task 
duration for each individual operation as well as the composite time duration 
for the entire block can be determined. For example, the third task shown, 
Move Spacelab to Orbiter Processing Facility (0PF) J was estimated to take 
2 hours; therefore, the task description is preceded by two asterisks that 
are shown to occur during the sixth and seventh hours of the first working 
day of Block 11.0. 

Activity Data Sheets 

The activity data sheets (ADS) are expanded definitions of each task 
that is part of a detail flow. In all cases, the detail flows represent 
expansions of the top-level functional blocks. The ADS were written to 
define operations and resource requirements at the lowest level of detail 
described by the detail flows. Figure A. 2-9 is an example of an activity 
data sheet that contains the tasks and operations for the preparations for 
and movement of the complete Spacelab to the OPF. This example details the 
first seven hours of tasks of the overall complete Spacelab operation. 

Block 11.0, Orbiter Cargo Integration. The detail flows and the activity 
data sheets for all applicable functional blocks of each concept were used 
to develop the integrated flows for each concept. The activity data sheets 
contain descriptions of the tasks, and the personnel, GSE and facilities 
necessary to complete the reference block. 
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ACTIVITY DATA SHEET 


1.0 ACTIVITY IDENTIFICATION 


Functional Flow Number: 11,1 


Applicable Concepts: 


Title: Preparations for and Moving Complete Spacelab to OPF 


Principal Elements: Spacelab /Orbiter/Tunnel 


2.0 ACTIVITY DESCRIPTION 

This subtask begins with connecting the lifting devices to the complete 
Spacelab, followed by loading operations Into the Spacelab shipping 
canister, and disconnection of lifting devices. Lifting devices are then 
connected to the canister for loading on the transporter. A blanket 
pressure (GN 2 ) might be placed Inside the canister to preclude entry of 
contaminated air during the move from the MSOB to the OPF. Some Spacelab/ 
experiment configurations may have unique cooling requirements; so for 
these configurations, special cooling systems may be necessary as paTt 
of the shipping canister design* It is clear that one would not have a 
shipping canister blanket pressure simultaneously with an air-conditioned 
canister interior; consequently, the Spacelab /experiment configuration 
is fundamental to the choice of method. The point of this discussion is 
to emphasise that the move preparations are dependent upon Spacelab /exper- 
iment configuration and therefore the estimates used are related to the 
three reference ATL payloads (see Appendix A) . 

The actual move of the complete Spacelab to the OPF from the MSOB requires 
about two hours because of very low transport speeds (•< 5 mph) necessary 
to mitigate road shock. 

At the OPF, the complete Spacelab is removed from the shipping canister, 
after off-load from the transporter, and placed in a suitable Spacelab/ 
Orbiter load preparation work stand. The GSE hatch cover and seal are 
removed from the SM hatch, and a hatch surface/seal protective cover is 
installed. Conditioned air and GSE lighting are installed and access 
stands set up to facilitate complete Spacelab preloading operations. 


Figure 4.2-9. Example Activity Data Sheet (Block 11.0) 
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Integrated Flows 

The integrated flows for all five complete Spacelab concepts are shown 
xn Figure 4.2-10. Complete Spacelab concepts I and V are related in that 
they involve the completion of all operations (other than Level I integration 
and the launch) at one center, the IC and user site, respectively. In the 
other three concepts the SM and EM shell are owned and maintained at the 
launch site. Both Levels II and I integration are accomplished at the launch 
site. Because of the variations between these groups of concepts, the most 
efficient method to illustrate significant differences while not losing the 
perspective of important similarities, was to group the flows together in the 
manner shown m Figure 4.2-11. The top portion of the integrated flow per- 
tains to the test and operations activities for Concepts I and V, and the 
bottom portion illustrates Concepts II, III, and IV. 

The initial 12.2 weeks of activities are common to all five complete 
Spacelab processing concepts. It is at this point that Concepts II, III, 
and IV deviate from Concepts I and V. Following the dashed-line down from 
the top flow will illustrate how the integrated flows for Concepts II and 
IV were defined. The bottom section of this figure contains the unique steps 
that differentiate Concept III from Concepts II and IV. The final five steps 
relate to the preparations for and the shipment of the racks, floor structure, 
aft bulkhead, and the pallet sections to the user's facility following refurb- 
ishment. The steps also include the shipment period (two days) and the 
receiving/inspection effort at the user's facility. 

The integrated flows were developed from the detail flows for each con- 
cept with proper allowances for work activities that can be accomplished in 
parallel. From the figure. Concepts I and V have the same processing flow 
timelines of 111.3 work days (single-shift 8-hour/day, 5-day /week schedule); 
this equates to 22.3 calendar weeks. Concepts II and IV also have the same 
processing cycles that equate to 115.8 work days, or 23.2 calendar weeks. 
Concept III is unique in that its processing cycle is 122.3 work days (24.5 
calendar weeks')^, or approximately- 2 weeks longer than for_Concepts I and_V. 

Summary of Processing Times 

A comparison of the basic test and operations processing times for all 
five complete Spacelab concepts is shown in Table 4.2-2. These times were 
established from the detail flows and the activity data sheets. Three time 
entries are presented. They are as follows. 

1. The basic block time (in work days) required to complete a 
given functional block. 

2. A column indicating the overlap times between functional 
blocks. For example, 2.5 days of the 5.7 days required for 
Block 3.0, Connect SM Interface Simulator > can be accomp- 
lished during the initial steps of Block 4.0. Therefore, 
only 3.2 days of serial processing time are included in the 
summary processing times for any concept that uses this 
block. 
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Table 4.2-2. Summary of Complete Spacelab Processing Times 


SERIAL PROCESSING TIMES 


MAJOR FUNCTIONAL ACTIVITY 


BLOCK 

TIME OVERLAP PARALLEL 
(DAYS) TIME TIMES 



♦OVERLAP TIME APPLICABLE TO 
CONCEPTS I & V ONLY 


Space Division 

Rockwell International 



















Space Division 

Rockwell International 


3. A column indicating parallel functional block activities. 

These blocks can be completely accomplished in parallel 
with other blocks and, as such, are not added to the 
composite overall complete Spacelab processing times. 

For example, functional block 1.0, Experiment Shipment } 
can be accomplished during post-flight refurbishment of 
Spacelab flight hardware. 

Block 13.0, Mission Operations , is included for reference. 

The baseline mission duration was 7 days, but the T&O time 
estimates were developed from a single-shift 8-hour/day 
5-day /week; therefore, to avoid potential confusion in 
converting from work days to calendar time, the one week 
of the mission has been defined as 5 days of serial 
processing time. 

The majority of the operations to be performed in any given 
concept is essentially the same. The significant differences 
between concepts are as follows. 

a. Concept III varies from Concepts II and IV by the 
additional 6.5 days required to ship the rack/pallet 
assembly to the user following refurbishment at 

the IC. This activity is unique to Concept III. 

b. Concepts II and IV vary from Concepts I and V by 

approximately 4.5 days. Concepts II and IV are 
longer because of two operations: (1) shipment of 

the complete Spacelab to the MSOB following a mission, 
where the complete Spacelab elements are demated and 
the rack and pallet prepared for shipment to the IC 
(an additional 2.6 days); and (2) shipment of racks 
and pallet is a 6.7-day operation, whereas complete 
Spacelab shipment is accomplished in 5.4 days. 

The remainder of the time difference between these concepts is due to small 
differences that result from parallel activity consequent to handling of the 
mated complete Spacelab (Concepts I and V) , as opposed to the handling of sep- 
arate Spacelab elements (rack/pallet assembly- SM/EM shell) of Concepts II 
and IV. 

Complete Spacelab Test and Checkout Requirements 

The composite set of test and checkout requirements (TCR) for the complete 
Spacelab are listed in the TCR matrix of Table 4.2-3. As shown in the table, 
each test requirement is cross-referenced to the work breakdown structure 
(WBS) under which the responsibility and costs for that item are collected. 
Further, each test requirement is identified against the particular functional 
block in which it is accomplished, along with its test integration level. 

The functional flow blocks that are necessary in the processing cycle, but which 
do not specifically generate test requirements are itemized in the footnotes of 
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Table 4. 2-3. Complete Spacelab TCR Matrix 



INTEGRATION 
WBS LEVEL 
RET NO 


IMMUl 



FUNCTIONAL FLOW BLOCK NUMBER* 








VERIFY PLUGS-OUT CONTINUITY Of RACKS/EXPMTS/EQUIP 
IEAK-CHK FLUID CONNECTIONS AT AFT BLKHD A PALLET I/T'S 


VERIFY SM l/T SIM mech/ellct CONNECTIONS WITH FACILITY 
VERIFY SM |/F SIMULATOR/RAO S/PALLET INTERFACES 
VERIFY SERV UNIT FLOW & CONTROL TO R/P COOLANT LOOPS 
PERFORM BUS ISOLATION TESTS OF RACE S/ExPMTS/PALLf T 
PERFORM ELECTRICAL POWER DISTRIBUTION TEST 
VERIFY CAUTION/WARNING CIRCUITRY 

PERFORM COMPUTER & INSTRUMENTATION SYST SELF-CHECKS 
VERIFY DMS COMMAND & CONTROL & PERIPHERAL EQUIPMENT 
VERIFY CRND DATA BASE (GD8) COMPAT VIA GDB UMBILICAL 
VERIFY RACFS'IXP AUX EQUIP — CCTV, INTERCOM. ETC 


VERIFY READINESS Of EXPMT OR SUPT FQUIP FOR ACTIVATION 
ACTIVATE CONTROL & DISPLAYS A SUPPORT EQUIPMENT 
VERIFY PERF OF C/D CONSOLT DURING EXPMT FUNCT C/O 
VERIFY OPER OF PALLET-MOUNTED DEPLOYABLE EXPMT EQUIP 
VERIFY OPER OF RACK- MOUNTED Mf CHANICAL EXPMT EQUIP 
VERIFY FUNCT OPERATION OF EXPIRJMENTS/SUPPORT EQUIPMENT 
VERIFY DATA PROCESSING/RECORDING EQUIP DURING EXPMT C/O 
CONDUCT EMIAFI TESTS 


CONDUCT SM/tM/PALLET FLECT BONDING CHECKS AFTER COMPLETE 
SPACELAB (SL) ASSEMBLY I 

CONDUCT A VERIFY ALL COMPLETE SL ElEC/MECH INTERFACES 


SERVICE A VERIFY COOLANT FLOW THROUGH GSE 

VERIFY ORBITER INTERFACE SIM OPERATIONAL CAPABILITY 

PERFORM COMPLETE SPACELAB BU5 ISOLATION TtSTS 

CONDUCT COMPLETE SL ELECTRICAL POWER DISTRIB TESTS 

VERIFY COMPLETE SPACFLAB C AV/ CIPCUiTKY 

CONDUCT COMPLETE SPACELAB COMPUTER SELF-CHECKS 

VERIFY COMPUTE SL DMS CMD'CONTROL A PERIPHERAL EQUIP 

VERIFY COMPLLTE SL AUX EQUIP -CCTV, INTERCOM, LIGHTING, ETC 

CHECK OUT SIG DISTRIBUTION VIA SM-ORBITER UMBILICAL 

VERIFY GDB OPERATION VIA GDB UMBILICAL 

CONDUCT FUNCT C/O OF COMPLETE SL SUPPORT SYSTEMS/ 

EXPMT EQUIPMENT INTERFACES 

CONDUCT EMISSIVITY TESTS OF COMPLETE SL EXTERIOR SURFACES 
CONDUCT COMPLETE SL 74- HR PRESS DECAY LK CHK 
CONDUCT COMPLETE SL WEIGHT/BALANCE TESTS 


PERFORM COMPLETE Sl/ORB PRllNST Al l INTERF VERIF TESTS j 

SERVICE COMPLETF 5L WITH NON-HA/ FLUIDS A LOW-PRESS GASES 
VERIFY ORBITER READINESS TO ACCEPT COMPLETE SPACELAB 
PERFORM ORBITFK/CCMPLETE SL 1 1 \ VERIFICATION TEST 
PERFORM ORBITFR INTEGRATED TEST (OIT) 

CONDUCT COMPLETE SPACELAB 'ORBITER EMl/RFI TESTS 
PERFORM ABBREVIATED LEAK CHECKS 
A TUNNEL 
I B TUNNEL HATCH 

I C COMPUTE bPACELAB |NTE p f ACTS 

PERFORM ORDNANCE INSTALLATION TESTS 

‘ CONDUCT COMPLETE SL FINAL PRELAUNCH TESTS 
I PERFORM COMPLETE SL HAZ MATFRIALS LOADING TESTS 


REFURBISH RACKS/PALLET 

A DRAIN, FLUSH, DRY A CAP COOLANT SYSTEM 
B REMOVE RACKS/EXPERIMENTS 
' C REFURBISH RACKS 

, D VERIFY OPERABILITY Of FLUID SYSTEM COMPONENTS 


1 REFURBISH SUPPORT SYSTEMS AND Sm/EM ASSEMBLY 
A DRAIN, FLUSH, DRY A CAP COOLANT SYSTEM 
B VERIFY OPERABILITY OF FLUID SYSTEM COMPONENTS 
C VERIFY OPERATION OF AIR REVITALIZATION SYSTEM 
D VERIFY OPERATION OF DMS COMPONENTS 
E VERIFY OPERATION OF CPSS (AIRLOCKS, IPS, ETC ) AS REQ 



NOTE THE FOLLOWING FUNCTIONAL FLOW BLOCKS INVOLVE SHIPPING 
MISSION & POST-FLIGHT OPERATIONS WHICH DO NOT CONTAIN 

, RECEIVING INSPECTION, MATING/DEMATING, INSTALLATION/REMOVAL, 
ANY TEST A CHECKOUT REQUIREMENTS 

) 0 EXPERIMENT SHIPMENT 

9 0 SPACELAB SHIPMENT 

14 0 

POST-FLIGHT OPERATIONS 

17 0 

DEMATE EM/SM SHELLS 

S 0 GSE DISCONNECT 

10 0 SPACELAB OFFLOAD 

15 0 

SPACELAB MOVE TO MSOB 

18 0 

RACKS/PALLET SHIPMENT 

6 0 RACKS/PAUFT SHIPMENT 

13 0 MISSION OPERATIONS 

16 0 

SPACELAB SHIPMENT FROM 
LAUNCH SITE 

20 0 
2? 0 

EXPERIMENTS SHIPMENT 
POST-REFURB RACKS/PALLET 
SHIPMENT 
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Table 4.2-3. Refer to Section 4.1 (Composite Requirements Matrix) of this 
volume for the guidelines and assumptions that werp used in the development 
of the TCR matrix. 

PALLET ONLY 

The data for the pallet-only processing concepts, described in the 
following paragraphs , were developed in the same manner as for the complete 
Spacelab. The data contained herein apply to three additional processing 
concepts which, for convenience, have been designated in contiguous numerical 
order with the complete Spacelab concepts (i.e.. Concepts VI, VII and VIII). 
This designation was chosen to reduce the possibility of confusion of concepts 
between the complete Spacelab and pallet-only configurations. A description 
of the pallet-only Spacelab configuration is presented in Section 5.0 of 
Volume I. 

Functional Block Diagram 

In the same manner as for the complete Spacelab, scenarios of all the 
processing operations were developed for each pallet-only concept. For the 
pallet-only concepts, 19 functional blocks were identified as being required 
to complete the processing cycle. These 19 blocks are illustrated in Table 
4.2-4. They are grouped by WBS number and integration level. The 60-00-50-XX 
entries relate to Level III integration, 63-00-50-XX to Level II, and the 
66-00-50-XX entries to Level I. 


Table 4.2-4. Pallet-Only Functional Block Identification 


WBS NO. 

BLOCK NO. 

FUNCTIONAL FLOW TITLE 

60-00-50-1.0 

1.0 

EXPERIMENT SHIPMENT 

-2.0 

2.0 

EXPMT INSTALLATION (PALLET/CANISTER) 

-3.0 

3-0 

CONNECT 6 C/0 1 GL00/0RB ITER SIMULATOR SET 

-4.0 

4.0 

EXPERIMENT CHECKOUT & INTEGRATION 

-5.0 

5-0 

GSE DISCONNECT 

-6.0 

6.0 

PALLET/IGL00 SHIPMENT 

-7.0 

7.0 

PALLET/IGL00 6 PSS EQUIP ARRIVAL S R/l 

-15.0 

15.0 

PALLET/IGL00 SHIPMENT 

-16.0 

16.0 

REMOVE EXPMTS/EQU 1 PMENT FROM PALLET/ IGLOO 

-17.0 

17-0 

EXPERIMENT SHIPMENT 

-18.0 

18.0 

REFURBISH/RECONFIGURE PALLET & IGLOOS 

-19.0 

19-0 

POST-REFURBISHMENT PALLET/ IGLOO SHIPMENT 

63-00-50-8.0 

Hi 

MATE PALLET 6 IGLOO (SUPPORT SYSTEMS) 

-9.0 

m 

SPACELAB INTEGRATION 

66-00-50-10.0 

10.0 

ORB ITER CARGO INTEGRATION 

-11.0 

11.0 

LAUNCH OPERATIONS 

-12.0 


MISSION OPERATIONS (REFERENCE) 

-13.0 


POST-FLIGHT OPERATIONS 

-14.0 


REFURBISH SUPPORT SYSTEMS IGLOO 
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Again, as in the complete Spacelab concepts, Block 12.0, Mission Opera- 
tions, has been included (estimated as 5 days) in order to be able to establish 
the total serial processing time for each of the three pallet-only concepts. 

The following paragraphs describe which functional blocks and detail flows 
pertain to each of the three pallet-only concepts. 

Concept VI 

The specific sequence and applicability of the functional blocks for 
Concept VI are illustrated m Figure 4.2-11. Note that all the functional 
blocks contained m Table 4.2-4 apply to this concept. Concept VI is char- 
acterized by the ownership of the support systems igloo by the LS , and 
pallet segments and experiment support canisters by the IC. Level III inte- 
gration is at the user facility, and Levels II and I integration is at the 
LS. The transfer of hardware between centers is illustrated by the center 
designated above a given functional block. Those transitional blocks that 
involve the shipment of hardware from one center to another have both centers 
identified above the blocks (i.e. , Block 15.0, Pallet /Igloo Shipment following 
the mission, is originated at the LS and concluded at the IC). 

Concept VII 

The applicable tasks are shown in Figure 4.2-12, which illustrates that 
Block 19.0, Post- Refurbishment Pallet/Igloo Shipment, is not applicable since 
the IC performs the refurbishment of this hardware and also experiment inte- 
gration at the same facility. 

Concept VIII 

The applicable tasks are illustrated in Figure 4.2-13, and Block 19.0 
is again not applicable because the user in this concept performs the refurb- 
ishment of the pallet/igloo , which is followed by experiment integration at 
the user's facility. There is no need to ship a refurbished pallet/igloo 
assembly to another center for Level III integration. 

Detail Flows 


The detail flows for the three pallet-only concepts were developed m 
the same manner as those for th° complete Spacelab concepts. The flows are 
time-sequenced expansions of all 19 functional blocks (listed in Table 4.2-4) 
that are required by the pallet-only concepts. 

Activity Data Sheets 

The activity data sheets (for the pallet-only concepts) which describe 
the individual tasks /operations of the detail flows are provided in Appendix 
D, Part II. Each activity data sheet is coded to indicate concept applica- 
bility. 

Integrated Flows 

Figure 4.2-14 illustrates the integrated flows for the pallet-only 
concepts. These flows were made from the detail flows of the pallet-only 
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▼ START CYCLE | | | | 

■ PREP S FOR INSTALL OF EXPMT'SUPPORT EQUIP 

^ ■ INSTALL EXPMTS/SUPPORT EQUIP CABLING LINES & BRACKETS ON PALLET & IGLOOS 

install expmts/support equip on pallet & iglooisi 
■ PERFORM CABLING CONTINUITY CHECKS 

Wm MATE PALLET & S S IGLOO SIMULATOR - CONNECT FLUID LINES - VERIFY INTERFACES 
V PREPS FOR PALLET - ORBITER SIMULATOR SET MATE 
■ ■ MOVE POSITION SIMULATOR SETS & SUPPORT GSE - VERIFY SIMUL SET FACILITY l/F S 
■ CONNECT PALLET SIMUL SET 'FACILITY INTERFACES 
■ PALLET SIMUL PRE POWER CHECKS (COOLANT LOOPS BUS ISOLATION & SW LIST VERIF ) 

▼ POWER UP PALLET & SIMULATORS 

■ CONDUCT PWR DIST CHECKS CAUTION & WARNING & COMPUTER INSTRU SELF CHECKS 
■ VERIFY IMS 'SIMULATOR COMMAND & CONTROL 

I VERIFY OPER OF SIMUL IMS PERIPHERAL EQUIP GRO DATA BASE COMPATIBI LITY AUX EQUIP 
I ▼ POWER DOWN PALLET & SIMULATORS 

■ EXPMT INTEGRATION READINESS REVIEW 
V TEST TEAM CALL TO STATION 
| PALLET & SIMULATORS SWITCH LIST VERIF 
* POWER UP PALLET & SIMULATOR SETS 

conduct individual expmt c o by discipline 

conduct expmts integrated sys & emc/rfi tests 
conduct crew training & abbreviated mission simulation 

▼ POWER DOWN PALLET & SIMULATOR SETS 
■ DATA REVIEW 

■ WORK DISCREPANT ITEMS & SYS RETEST 
■ ACCEPTANCE DATA REVIEW 

■ DISCONNECT SIMUL SETS/AUXIL GSE & POST TEST CLEAN UP 
■ REMOVE EXPMT SUPPORT EOUIP FROM PSS SIMULATOR 
t CLOSEOUT PALLET PANELS COVERS & ACCESS DOORS 
■ PREPARE PSS MOUNTED EQUIP FOR SHIPMENT TO LS 
■i PREPS FOR SHIPMENT OF PALLET TO L S 
V SHIP PALLET & PSS EOUIP TO L S 
■■ PALLET & PSS EQUIP ENROUTE TO L S 
▼ ARRIVAL AT LS 

■ OFF LOAD PALLET & LOAD ON WORK DOLLY 
■ REMOVE PANELS & COVERS CONDUCT R/l 
■■ OFF LOAD PSS EQUIP & CONDUCT R/l 
fl POST R/l SECURE 

a MOVE PALLET TO INTEG AREA (MSOB) & VERIFY MATING READINESS 
■ INSPECT /VERIFY ELECT/MECH CONNECTIONS 
■ ALIGN IGLOOS & PALLET MATE VERIFY ELECT GND AT P/IGL l/F 
a CONNECT ELECT/MECH l/F S 

■ CONNECT GSE (SERVICE UNITS ORB l/F SIMUL & OTHER SUPPORT GSE) 

8 SERVICE & VERIFY COOLANT FLOW THROUGH GSE FLUID LINES & COLD PLATES 
I PERFORM BUS ISOLATION TESTS 
| CONDUCT PRE POWER SWITCH LIST CHECK 
I POWER UP ELECT & FLUID SYS & CONDUCT PWR OIST CHECKS 
I VERIFY C&W COMPUTER SELF CHECKS PWR UP SUPP SYS IGLOO IMS 
B VERIFY IMS COMMAND/CONTROL 

1 C/O OPER OF IMS PERIPHERAL EOUIP SIG DIST GDB COMPATIBILITY 
■I CONDUCT FUNCTIONAL C/O OF SUPP SYS IGLOO/EXPMT EQUIP l/F 
PWR DOWN PALLET/IGLOOS & SUPPORT EQUIP 
m DATA REVIEW 

m DISCONNECT GSE & LOAD NON HAZARDOUS SUPPLIES & CREW EQUIP 
B CLOSEOUT P/IGL PANELS HATCHES & ACCESS PANELS 
■ RETOUCH PALLET/IGLOO EXTERIOR SURFACES WITH THERMAL PAINT 
■ CONDUCT EMISSIVITY TESTS 
■ PREP IGLOOS FOR PRESSURE DECAY LEAK CHECK 
■ CONDUCT IGLOO LEAK CHECK (24 HR PRESS DECAY - 16 HR ON 2 & 3RD SHIFT) 

■ DEPRESSURIZE IGLOOS & REMOVE GSE 

■ CONDUCT WEIGHT & BALANCE TEST 
I PREPS FOR MOVE TO OPF 

' I MOVE P/IGL & PSS EQUIP TO OPF 

I OFFLOAD P/IGL & PSS/ORB EOUIP REMOVE LIFTING DEVICES 
▼ VERIFY ORBITER READINESS 

INSTALL P/L RELATED EQUIP IN PSS INSPECT ELECT/MECH l/F LOAD NON HAZARO 

Vrj FLUIDS LOW PRESS GAS , 

▼ VERIFY ORB READINESS TO ACCEPT PALLET/IGLOO 

Oq I CONNECT LIFTING DEVICES TO PALLET • 

c . 16 hr work day iorbiter time line) 

Z ll LOAD P/IGL IN ORBITER - VERIFY PLUGS OUT CONTINUITY 

ft) I ORBITER/PALLET/IGLOO INTERFACE VERIFICATION 

I CONDUCT (OlT) WITH ORBITER/P/IGL SYSTEMS I 

js I EMC/RFI TEST WITH OR8/P/IGL SYSTEMS OPERATING 

J" I INSTALL/CONNECT ORDINANCE NOT ACCESSIBLE AT PAD 

I ^ | DATA REVIEW- FINAL SL FLIGHT APPROVAL 

, B SL LAUNCH OPERATIONS , 

‘ ▼ LAUNCH 

MISSION OPERATIONS REF 

f 1 m 16 HR WORK DAY I 

▼ ORBITER LANDING 
■ ORBITER POST LANDING ACTIVITIES 

^ ^ (SAFING/PALLET REMOVAL) 

O y I REMOVE EXPMT EQUIP FROM PSS & CONNECT LIFTING 

W DEVICES TO PALLET 

2 ■ PREP & SHIP PSS/ORB MOUNTED EXPER EQUIP TO USER/IC 

g Jr a LOAD P/IGL IN SHIPPING CONTAINER & SECURE, REMOVE 

__ _ _ SUPPORT SYS IGLOO MOVE TO REFURB AREA 

? " ... - ■ INSTALL SHIPPING CONTAINER COVER & PORTABLE PRESS 

H I v UNIT ACTIVATE 

Q B MOVE P/IGL B. PSS EQUIP TO POINT OF EMBARKATION 

W 3 VSHIP 

. M MM P/IGL & PSS EQUIP ENROUTE FROM LS 

<^< ▼ PSS EQUIP ARRIVAL AT USER/PI 

▼ P/IGL ARRIVAL AT OWNER S FACILITY 

H BBB OFFLOAD P/IGL & LOAD ON WORK DOLLY 

tL ** ■ REMOVE PANELS/COVERS & CONDUCT R/1 

O REMOVE EXPMTS & SUPPORT EQUIP FROM 

5 PALLET/IGLOO 

O M I* REMOVE EXPMT SYS CABLING LINES & 

C 3 BRACKETS FROM P/IGL I 

C/3 m Wmm REFURBISH/RECONFIGURE 1 

© ^ ^ AX PALLET/IGLOOS 1 

l ^ Xj ■■ PREP EXPMTS FOR SHIPMENT TO 

^ S 2 USER/PI FACILITY 

■P" JT □ ZL ▼ SHIP EXPMTS TO USER/PI 

1 - Lj (A « EXPMTS ENROUTE TO USER/PI 

C/3 n FACILITY 

> ▼ EXPMTS/EQUIP ARRIVAL AT 

l -y ^ USER/PI FACILITY 

2 -j M I* PREPS FOR SHIPMENT OF 

Cl 00 Q • PALLET/IGLOO 

g* g : ▼ SHIP P/IGL TO USER FACILITY 

^ I H P/IGL ENROUTE 

! ▼ ARRIVAL AT USER 

J FACILITY 

! ■ OFFLOAD P/IGL & 

• LOAD ON WORK DOLLY 

• I REMOVE PANELS & 

I . COVERS CONDUCT R/l 

• | ▼ STOP CYCLE 

, j CONCEPT V) J 

I CONCEPTS VII W STOPCYCLd 
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configuration. The integrated flows consider tasks that can be performed in 
parallel to minimize the overall processing timelines. The integrated flows 
for Concepts VII and VIII are identical. The cycle for these two concepts 
ends with the refurbishment of the pallet segments and experiment equipment 
canisters. Concept VI includes all the tasks of Concepts VII and VIII plus 
an additional seven tasks. These additional tasks are illustrated in Figure 
4.2-14, after completion of the ground operations cycle for Concepts VII and 
VIII. The additional tasks involve the preparation and shipment of pallet 
segments and experiment equipment canisters from the IC to the user center 
for Level III integration of the payload for a subsequent flight. Post-flight 
refurbishment and Level III integration are accomplished at the same site in 
Concepts VII and VIII and, thus, a post-refurbishment shipment is not required 
in these two concepts. The total processing times for Concepts VII and VIII 
are identical; the processing time for Concept VI is 5.6 days longer. 

Summary of Processing Times 

The processing times for each pallet-only concept are illustrated in 
Table 4.2-5. The processing times are listed for each concept by functional 
block. Work days required to complete each particular functional block are 
indicated. Where applicable, overlap time between blocks is indicated. 

For example, the time required to complete Block 3.0 was estimated to be 
5.7 days, but 3.7 days of the activity can be performed in parallel with the 
subsequent activity (Block 4.0). Therefore, only two additional days are 
added to the serial processing time estimates. Parallel functional block 
activities are also indicated. Entries were made for those blocks that are 
accomplished entirely in parallel with some other functional block; and 
therefore, do not add any serial processing time to the total for any concept 
that utilizes these blocks. 

The data of Table 4.2-5 indicate that both Concepts VII and VIII require 
106.1 work days. For a 5-day/week, 8-hour/day, this equates to 21.2 calendar 
weeks. Concept VI requires a processing time of 111.7 work days (22.3 cal- 
endar weeks), or an additional 1.1 weeks is required to complete those activities 
related to the seven additional operations involved m the preparation and ' 
shipment of the pallet segments and experiment equipment canisters from the 
IC to the user facility. In Concept VI, these equipment items are refurbished 
at the IC and sent to the user where Level III integration (experiment instal- 
lation and checkout) is conducted. 

Pallet-Only Test and Checkout Requirements 

The composite set of test and checkout requirements for the pallet-only 
concepts is illustrated in Table 4.2-6. This matrix for the pallet-only 
concept was developed in a manner identical to the complete Spacelab version 
(Table 4.2-3). As shown in Table 4.2-6, each test/checkout requirement is 
cross-referenced to the WBS number under which the responsibility and costs 
for that item are collected. Further, each test requirement is identified 
against the particular function block in which it is accomplished along with 
the associated test integration level. The functional flow blocks that are 
necessary in the processing cycle, but which do not specifically generate 
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Table 4.2-5. Summary 


i 

CD 

o 


CO 

t) 

-O 

I 

CO 

*r 

o 

M 

Ln 

ON 


BLOCK 

MAJOR FUNCTIONAL ACTIVITY 

1.0 

EXPERIMENT SHIPMENT 

EB9 

EXPMT INSTALLATION (PALLET/IGL00) 

1111 

CONNECT & C/0 IG100/0RBITER SIM SET 

4.0 

EXPERIMENT CHECKOUT & INTEGRATION 

5.0 

GSE DISCONNECT 

6.0 

PALLET/IGL00 SHIPMENT 

7.0 

PALLET/IGLOO & PSS EQUIP ARRIV & R/I 

8.0 

MATE PALLET & IGLOO (SUPPORT SYSTEM) 

9.0 

SPACELAB INTEGRATION 

10.0 

ORBITER CARGO INTEGRATION 

11.0 

LAUNCH OPERATIONS 

12.0 

MISSION OPERATIONS (REF) 

13.0 

POST-FLIGHT OPERATIONS 

14.0 

REFURBISH SUPPORT SYSTEMS IGLOO 

15.0 

PALLET/IGLOO SHIPMENT 

16.0 

REMOVE EXPMTS/EQUIP FROM PALLET/ IGLOO 

17.0 

EXPERIMENT SHIPMENT 

18.0 

REFURB/RECONFIG PALLET & IGLOOS 

19.0 

POST-REFURB PALLET/IGLOO SHIPMENT 

TOTAL WORK DAYS 


Pallet-Only Processing Times 


BLOCK TIME 
(DAYS) - 

OVERLAP 

TIME 

PARALLEL 

TIME 

SERIAL 

PROCESSING TIME | 

VI 

VII 

VIII 

7. 0/1.0 


X 




21.0 



21.0 

21.0 

21.0 

5.7 

3.7 


2.0 

2.0 

2.0 

36.0 



36.0 

36.0 

36.0 

2.5 


X 




3.5 



3.5 

3.5 

3.5 

2.4 



2.4 

2.4 

2.4 

2.7 



2.7 

2.7 

2.7 

10.2 



10.2 

10.2 

10.2 

4.2 



4.2 

4.2 

4.2 

4.2 



4.2 

4.2 

4.2 

5.0 



5.0 


5.0 

1.9 



1.9 

1.9 

1.9 

7.5 


X 




5.0 



5.0 

5.0 

5.0 

5.0 



5.0 

5.0 

5.0 
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X 




3.0 



3.0 

3.0 

3.0 

5.6 



5.6 



134.9/128.9 

KB 

17/11 

111.7 
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106.1 

TOTAL CALENDAR WEEKS 
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TOTAL CALENDAR MONTHS 
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Table 4.2-6. Pal let -Only TCR Matrix 


LINE WBS INTEGRATION 
ITEM REF NO LEVEL 



FUNCTIONAL FLOW BLOCK NUMBER 





VERIFY PUJGS-OUT CONTINUITY OF EXPERIMENT 

igloosaxperiments/equipment 

LEAK CHECK FLUID CONNECTIONS AT PALLET/1GLOQ/ 


VERIFY SUPPORT SYSTEMS IGLOO & ORBITER SIM SETS 
ELECT/MECH CONNECTIONS WITH FACILITY 
VERIFY SS IGLOO SIM/ORB SIM/EXPMT IGLOOA INTERFACES 
VERIFY SERVICING UNITS FLOW 4 CONTROL TO PAILET/IGLOO 
COOLANT LOOPS 

PERFORM BUS ISOLATION TESTS OF PALLET/1GLOO EXPMTS 
PERFORM ELECTRICAL POWER DISTRIBUTION TESTS 
VERIFY CAUTION/WARNING CIRCUITRY 
PERFORM COMPUTER 4 INSTRUMENTATION SYS SELF-CHECKS 
VERIFY IMS COMMAND/CONTROL 4 PERIPHERAL EQUIPMENT 
VERIFY PALLET /IGLOO AUX EQUIP— CCTV, INTERCOM. ETC 
VERIFY GDB COMPATIBILITY WITH GDB UMBILICAL 


VERIFY READINESS OF EXPMTS 4 SUP EQUIP FOR ACTIVATION 
ACTIVATE PALLET/IGLOO, CONTROL 4 DISPLAYS 4 SUP EQUIP 
VERIFY PERFORMANCE OF C4D CONSOLE DURING EXPERIMENT 
FUNCTIONAL TESTS 

VERIFY OPERATION OF PALLET-MOUNTED DEPLOYABLE 
EXPERIMENT EQUIPMENT 

VERIFY OPERATION OF EXPERIMENT /IGLOO MOUNTED 
MECHANICAL EQUIPMENT 

VERIFY FUNCT OPERATION OF EX PMT S/SUPPORT EQUIPMENT 
VERIFY DATA PROCESSING/RECORDING EQUIPMENT DURING 
EXPERIMENT CHECKOUT 
CONDUCT EMI/RFI TESTS 


CONDUCT PALLET/SS IGLOO ELECTRICAL 80NDING TESTS 
AFTER PAllET/SS IGLOO MATING 
CONDUCT 4 VERIFY PALLCT/SS IGLOO ELECT/MECH INTERFACES 


SERVICE 4 VERIFY COOLANT FLOW THROUGH GSE 
VERIFY ORBITER INTERFACE SIM OPERATIONAL CAPABILITY 
PERFORM PALLET/SS IGLOO BUS ISOLATION TESTS 
CONDUCT PALLET/SS IGLOO ELECT PWR DISTRIBUTION TESTS 
VERIFY PALLET/SS IGLOO CAUTION/WARNING CIRCUITRY 
CONDUCT SS IGLOO COMPUTER SELF-CHECKS 
VERIFY SS IGLOO IMS COMMAND/CONTROL 4 PERIPHERAL EQ 
VERIFY PALLET/SS IGLOO AUX EQUIP— CCTV, INTERCOM, ETC 
VERIFY SIG DISTR VIA SS IGLOO/ORBITER UMBILICAL 
VERIFY GDB OPERATION VIA THE GDB UMBILICAL 
CONDUCT FUNCTIONAL CHECKOUT OF IGLOO SUPPORT 
SYSTEM/EXPERIMENT EQUIPMENT INTERFACES 
CONDUCT EMISSIVITY TESTS OF PALLET/SS IGLOO 
EXTERNAL SURFACES 

CONDUCT SS IGLOO 24-HR PRESSURE DECAY LEAK CHECK 
CONDUCT PALLET/SS IGLOO WEIGHT/BALANCE TEST 


PERFORM PALLET /IGL/ORB PRE-INSTLN l/F VERIFICATION TESTS 
SERVICE PAllET/iGLOO WITH NON-HAZARDOUS FLUIDS AND 
LOW PRESSURE GASES 

VERIFY ORBITER READINESS TO ACCEPT PALLET/IGLOO 
PERFORM PALLET/IG LOO/OR BIT ER INTERFACE VERIFICATION TEST 
PERFORM ORBITER INTEGRATED TEST <OIT) 

CONDUCT ORBIT ER/PALLET/lGLOO EMC/RFI TESTS 
PERFORM ORDNANCE INSTALLATION TESTS 


CONDUCT FINAL PALLET/IGLOO PRELAUNCH TESTS 
PERFORM PALLET/IGLOO HAZARDOUS MATERIALS LOAD TESTS 


REFURBISH SUPPORT SYSTEMS IGLOO 

A DRAIM FLUSH, DRY 4 CAP COOLANT SYSTEM 
B VERIFY OPERABILITY OF FLUID SYST COMPONENTS 
C INSPECT/REPAIR ELECT CA8LES/CONNECTORS AND 
FLUID LINES 

D REFURBISH 4 VERIFY OPERATION OF IMS COMPONENTS 
E. INSPECT/REPAIR SS IGLOO MATING SURFACES 
F INSPECT/REPAIR SS IGLOO STRUCT STRESS/DAMAGE 


REMOVE EXPMTS, CABLES, LINES 4 BRACKETS FROM P/lGLOO 


REFURBISH/RECONFIGURE PALLET AND IGLOOS 

A DRAIN, FLUSH, DRY 4 CAP COOLANT SYSTEM 
B VERIFY OPERABILITY OF FLUID SYST COMPONENTS 
C VERIFY OPERABILITY OF PALLET/IGLOO POWER 
CONDITIONING SYSTEM 

D INSPECT/REPAIR PALLET/IGLOO ELECTRICAL CABLES/ 
CONNECTORS 4 FLUID LINES 
E INSPECT/REPAIR PALLET/IGLOO MATING SURFACES 

F INSPECT/REPAIR PALLET STRUCT STRESS/DAMAGE 


THE FOLLOWING FUNCTIONAL FLOW BLOCKS INVOLVE SHIPPING, RECEIVING INSPECTIONS, MATING/DEMATING, INSTALLATION/REMOVAL, 
MISSION 4 POST-FLIGHT OPERATIONS WHICH DO NOT CONTAIN ANY TEST AND CHECKOUT REQUIREMENTS 

1.0 EXPERIMENT SHIPMENT 7 0 P/IGLOO 4 PSS EQUIP ARRIVAL 4 R/l 15 0 PALLET/IGLOO SHIPMENT 

5 0 GSE DISCONNECT 1 2 0 MISSION OPERATIONS (REF) 17 0 EXPERIMENT SHIPMENT 

6 0 PALLET/IGLOO SHIPMENT 13 0 POSTFUGHT OPERATIONS 19 0 POST-REFURB PALLET/IGLOO SHIPMENT 








15 0 PALLET/IGLOO SHIPMENT 

17 0 EXPERIMENT SHIPMENT 

19 0 POST-REFURB PALLET/IGLOO SHIPMENT 
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test requirements, are itemized in the footnote of the table. The guidelines 
and assumptions utilized in the development of this matrix are described in 
Section 4.1 of this volume. 

TEST AND OPERATIONS RESPONSIBILITY ASSIGNMENTS 

Responsibility criteria and assignment of tasks for test and operations 
activities are presented in the subsequent paragraphs. 

Assignment Criteria 


The assignment of personnel for the Spacelab program in the test and 
operations area was based upon the following criteria. 

• Maximum involvement of the principal investigator (PI) , his 
designee, and/or the payload specialists. 

• Experiment discipline specialists (one for each technology 
area) will participate in the entire processing cycles of 
the equipment associated with their discipline. 

• Each site maintains its own technician work force. 

• Multi-skilled personnel will be chosen to the maximum 
possible extent. 

• The same technicians that work on the flight hardware will 
perform GSE revalidation. 

• In general, technicians will be resident personnel. Off-site 
support by this skill-level will be minimized. 

• The site at which test and/or operation is conducted will have 
the primary responsibility for the accomplishment of the associ- 
ated activities. 

Task Responsibilities 

The PI, his designee, and/or the payload specialists will be involved 
throughout the hardware processing cycle as consultants/participants for the 
experiment system tests for which they are responsible. The PI will have 
the final authority for the conduct of the testing which directly affects 
his experiment. The implementation of this authority, however, will be 
restricted to direction that does not compromise safety procedures or poten- 
tially cause damage to other experiment systems. The specific responsibilities 
of the PI are as follows. 

• Documentation. Prepares documentation relevant to his experiments 
including environmental compatibility certification, safety com- 
pliance, and acceptance test results. Defines checkout procedures 
suitable for incorporation into an overall test and checkout pro- 
cedure, and reviews /approves final proecedures and test results. 
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• Specialized GSE. Provides all special or experiment-unique GSE 
including development, qualification, maintenance, checkout, 
revalidation , and calibration. 

• Data Review. Contributes information pertinent to assigned 
experiments for the preparation of installation, checkout, 
and transportation procedures. 

• Experiment Refurbvshment. Assures that experiments that are to 
be reflown have been refurbished to flight-readiness standards, 
including experiment-related equipment. 

The experiment discipline specialists should have a working knowledge 
of the ATL experiment designs within their area of responsibility, and act 
as the interface between the PI and the test and operations personnel. In 
this way, a specialist may have the responsibility of coordinating the 
checkout activities of several experiments and, at the same time, be respons- 
ible to several Pi's. The discipline specialists will follow their experi- 
ments throughout the processing cycle of the flight hardware. 

The technician workforce will be (as a goal) comprised of multi-skilled 
personnel. Each site will maintain its own technicians. Local hiring will 
be the preferred method to reduce per-diem costs. During slack periods, the 
technicians can be utilized to perform related Spacelab activities such as 
GSE revalidation and maintenance. 

The resident test engineers will be responsible for the orderly and 
timely accomplishment of all tests and operations at a given site. Pi's, 
payload specialists, and test engineers from other sites where previous 
checkout activities occurred will participate in these test and operations 
activities. 
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5.0 INTEGRATOR INVOLVEMENT IN EXPERIMENT DEVELOPMENT 


Throughout the development of the support functions and test and opera- 
tions tasks associated with the integration and checkout of a Spacelab payload, 
the interrelationship between the PI and the payload integrator has been 
delineated. In this section, a summary of the payload integrator's role in 
experiment systems development is presented. 

SUPPORT FUNCTION INVOLVEMENT 

The non-recurring documentation effort provides the framework within which 
the PI will define/develop his experiment systems. The payload integrator must 
provide Spacelab and Orbiter payload accommodations handbooks to the Pi's. In 
addition, the integrators should provide a design handbook that delineates 
allowable materials, weights, cables, mounts, etc., and preferred assembly, 
test, handling, and checkout procedures. Safety and instrumentation/data 
processing guidelines should also be included. Software development guidelines 
should reflect the capability/capacity of the Spacelab data management system. 

PI mission planning and mission operations tasks can be significantly 
simplified if the integrator provides various software tools. These tools 
should be the same as those the integrator will use in combining all the 
experiment systems operations of a given payload. For example, the computer 
program to derive the total crew mission timeline should be provided to the 
PI to develop the crew timeline for an individual experiment. 

Configuration control is the responsibility of the integrator — not the 
PI. The integrator will perform this service throughout the development 
phase. Included m this service is the identification of appropriate common 
payload support equipment. 

Hardware integration will require the allocation of space and wiring to 
accommodate several experiment systems. The payload integrator will design 
and fabricate the required cables and mounting brackets that are not specific- 
ally related to the experiment system design. Where appropriate, the inte- 
grator will provide these cables/mounts to the PI for Level IV integration 
(PI acceptance tests). 

One of the most important services that the payload integrator could 
provide to the PI is standardized identification of experiment system require- 
ments. The integrator has the visibility to establish the required depth and 
breadth of data to combine multiple experiment systems. By providing standard 
formats for identification of requirements such as measurements, command/con- 
trol, telemetry, ground truth, trajectory, lighting, data processing, power, 
cooling, display, recording, etc., the task of the PI can be simplified. The 
PI will know specifically what data the integrator requires. Both multiple 
iterations and over-stipulation of requirements can be avoided. 
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TEST AND OPERATIONS INVOLVEMENT 

As the integrator is responsible for interfacing cables and mounts, it 
would be advisable to have integrator test personnel participate in Level IV 
integration activities. This participation would facilitate the incorporation 
of any required change in the flight hardware. 

Environmental compatibility certification is probably the primary role 
of the payload integrator in experiment systems development. Based upon data 
from previous flights the integrator can, with proper analysis techniques, 
minimize the environmental qualification testing of experiment equipments. 
Utilization of verified environmental models coupled with actual flight data 
on previously flown experiment equipments will provide the payload integrator 
with the visibility to recommend to the PI the most efficient technique for 
environmental certification. The integrator may alleviate a potential envir- 
onmental problem by recommending shock/vibration/acoustic mounts or devices 
that could also negate equipment qualification testing. 

INVOLVEMENT SUMMARY 

Except for safety considerations, the previously identified activities 
of the payload integrator during experiment development are not mandatory. 
However, all the activities are recommended and were incorporated in the 
definitization of the candidate processing concepts. It is believed that 
these payload integrator activities will simplify the tasks of the Pi's, 
reduce the costs of development of experiment systems, and facilitate the 
integration and checkout of multiple experiment systems. 
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